"Matthias Urlichs" <smurf@noris.net> writes:
>>>> Nonono, the 1000 read() calls are triggered by a simple INSERT or UPDATE
>>>> call. They actually scan the pg_index table of the benchmark database.
Ohh ... pg_index is the culprit! OK, I know exactly where that's coming
from: the planner is looking around to see what indexes might be
interesting for planning the query. Several comments here:
1. Probably we ought to try to bypass most of the planning process for
a simple INSERT ... VALUES. (I thought I had fixed that, but apparently
it's not getting short-circuited soon enough, if the search for indexes
is still happening.)
2. The search is not using either an index or a cache IIRC. Needs to
be fixed but there may be no suitable index present in 7.0.
3. I have been toying with the notion of having relcache entries store
information about the indexes associated with the table, so that the
planner wouldn't have to search through pg_index at all. The trouble
with doing that is getting the info updated when an index is added or
dropped; haven't quite figured out how to do that...
regards, tom lane
