Re: Look at heap_beginscan() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Look at heap_beginscan()
Date
Msg-id 2665.960363196@sss.pgh.pa.us
Whole thread Raw
In response to Look at heap_beginscan()  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Look at heap_beginscan()
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Joe Brenner
Date:
Subject: Re: OFFTOPIC: SQL book
Next
From: Tom Lane
Date:
Subject: Re: Use of system indexes