Re: B-Tree support function number 3 (strxfrm() optimization)

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id 20140408214851.GO5822@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: B-Tree support function number 3 (strxfrm() optimization)  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
Peter Geoghegan wrote:

> What I have here looks like it speeds things up a little over 200% (so
> a little over 300% of the original throughput) with a single client
> for many representative cases. That's a massive difference, to the
> point that I don't see a lot of sense in considering fmgr-elision
> alone separately.

I think the point here is what matters is that that gain from the
strxfrm part of the patch is large, regardless of what the baseline is
(right?).  If there's a small loss in an uncommon worst case, that's
probably acceptable, as long as the worst case is uncommon and the loss
is small.  But if the loss is large, or the case is not uncommon, then a
fix for the regression is going to be a necessity.

You seem to be assuming that a fix for whatever regression is found is
going to be impossible to find.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Default gin operator class of jsonb failing with index row size maximum reached
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: default opclass for jsonb (was Re: Call for GIST/GIN/SP-GIST opclass documentation)