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
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 |