Re: [GENERAL] Multiple Indexing, performance impact - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] Multiple Indexing, performance impact
Date
Msg-id 6450.993252598@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] Multiple Indexing, performance impact  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> This does remind me that I'd been thinking of suggesting that we
>> raise the default -B to something more reasonable, maybe 1000 or so
>> (yielding an 8-meg-plus shared memory area).

> On Modern(tm) systems, 8 MB is just as arbitrary and undersized as 1 MB.

A fair complaint, but at least it's within an order of magnitude of
being reasonable; you don't *have* to tune it before you get something
approaching reasonable performance.  64 is two or more orders of
magnitude off.

> So while for real use, manual tuning will still be necessary, on test
> systems we'd use significant amounts of memory for nothing, or not start
> up at all.

The thought of test postmasters was what kept me from proposing
something even higher than 1000.  8Mb is small enough that you can
still expect to run several postmasters without problems, on most
machines where you might contemplate the idea of multiple postmasters
at all.

Would you suggest that we have no default at all, and make users pick
something?

> Maybe we could look around what the default limit is these days, but
> raising it to arbitrary values will just paint over the fact that user
> intervention is still required and that there is almost no documentation
> for this.

We do need to have a section in the administrator's guide about tuning.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [GENERAL] Multiple Indexing, performance impact
Next
From: Peter Eisentraut
Date:
Subject: Re: [GENERAL] Multiple Indexing, performance impact