Re: Performance (was: The New Slashdot Setup (includes MySql server))

"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