Re: Abbreviated keys for Numeric

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Abbreviated keys for Numeric
Дата
Msg-id 87a8z39zk8.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Abbreviated keys for Numeric  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Abbreviated keys for Numeric  (Peter Geoghegan <pg@heroku.com>)
Re: Abbreviated keys for Numeric  (Robert Haas <robertmhaas@gmail.com>)
Re: Abbreviated keys for Numeric  ("ktm@rice.edu" <ktm@rice.edu>)
Список pgsql-hackers
>>>>> "Peter" == Peter Geoghegan <pg@heroku.com> writes:
Peter> As I said, I don't really consider that my patch is a rewrite,Peter> especially V4, which changes nothing
substantiveexcept removingPeter> 32-bit support.
 

Well, that's a hell of an "except".

Here's my main arguments for why 32bit support should be kept:

1. It exists and works well (and yes, I have tested it).

2. This optimization is a huge win even on very small data sets. On
sorts of as few as 100 items it gives detectable (on the order of +50%)
improvements.  On 1000 items the speedup can easily be 3 times. So it's
not just people with big data who want this; even small databases will
benefit.

3. Keeping the 32bit support (and desupporting DEC_DIGITS != 4) makes it
unnecessary to have #ifdefs that disable the numeric abbreviation
entirely.  (You don't even need those for comparative performance
testing; easier to do that by tweaking the catalogs.)

As against that, you have the fact that it's ~70 lines of code in one
self-contained function which is 32bit-specific.

So what do other people think?

-- 
Andrew (irc:RhodiumToad)



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: logical column ordering
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: logical column ordering