Re: Abbreviated keys for Numeric

Поиск
Список
Период
Сортировка
От ktm@rice.edu
Тема Re: Abbreviated keys for Numeric
Дата
Msg-id 20150324130020.GA28249@aart.rice.edu
обсуждение исходный текст
Ответ на Re: Abbreviated keys for Numeric  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Список pgsql-hackers
On Mon, Mar 23, 2015 at 09:41:40PM +0000, Andrew Gierth wrote:
> >>>>> "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 substantive except removing
>  Peter> 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?
> 

+1 for including 32-bit support as well. This is a tremendous performance
increase and users of older systems will benefit, and should benefit.

Regards,
Ken



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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Performance improvement for joins where outer side is unique
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Zero-padding and zero-masking fixes for to_char(float)