Re: Look at heap_beginscan()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Look at heap_beginscan()
Date: 2000-06-07 07:33:16
Message-ID: 2665.960363196@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Just do a search for heap_beginscan() and look at all those system table
> heap scans. Clearly, for large installations, we should be doing index
> scans.

There are a bunch of heap_beginscan() calls, but my first impression
from a quick scan is that most of them are in very non-performance-
critical paths --- not to mention paths that are deliberately ignoring
indexes because they're bootstrap or reindex code. Furthermore, some
of the remainder are scans of pretty darn small tables. (Do we need
to convert sequential scans of pg_am to indexed scans? Nyet.)

I'd be real hesitant to do a wholesale conversion, and even more
hesitant to add new system indexes to support indexscans that we
have not *proven* to be performance bottlenecks.

It's certainly something worth looking at, since we've identified
a couple of places like this that are indeed hotspots. But we need
to convince ourselves that other places are also hotspots before
we add overhead in hopes of making those places faster.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2000-06-07 07:35:40 Re: Use of system indexes
Previous Message Joe Brenner 2000-06-07 07:33:10 Re: OFFTOPIC: SQL book