Re: [GENERAL] Multiple Indexing, performance impact

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] Multiple Indexing, performance impact
Дата
Msg-id 6450.993252598@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: [GENERAL] Multiple Indexing, performance impact  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [GENERAL] Multiple Indexing, performance impact
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [GENERAL] Multiple Indexing, performance impact