Re: 8.3devel slower than 8.2 under read-only load

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: 8.3devel slower than 8.2 under read-only load
Дата
Msg-id 13678.1196088920@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: 8.3devel slower than 8.2 under read-only load  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: 8.3devel slower than 8.2 under read-only load  (Simon Riggs <simon@2ndquadrant.com>)
Re: 8.3devel slower than 8.2 under read-only load  (Simon Riggs <simon@2ndquadrant.com>)
Re: 8.3devel slower than 8.2 under read-only load  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> But I think there must be an action that we can take for 8.3 and that
> much runtime should not be given away easily. ISTM that we can win back
> the losses Guillaume has identified, plus gain a little more even.

Perhaps some sanity could be restored to this discussion by pointing out
that the 2007-01-01 code *also* clocks in at 37% spent in
oper_select_candidate.  IOW it's been like this for a very long time.
I'm not interested in destabilizing 8.3 with panicky last-minute patches.

> So how about we have a cache-of-one:

Cache-of-one has exactly the same difficulty as cache-of-many, other
than the table lookup itself, which is a solved problem (hashtable).
You still have to determine how you identify the cached value and what
events require a cache flush.  Nor do I see any particular reason to
assume that a cache of only one operator would be of any use for
real-world apps, as opposed to toy examples.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Cave-Ayland
Дата:
Сообщение: Locating sharedir in PostgreSQL on Windows
Следующее
От: Tom Lane
Дата:
Сообщение: initdb for RC1 (was Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?)