Re: Re: Abbreviated keys for Datum tuplesort

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Re: Abbreviated keys for Datum tuplesort
Дата
Msg-id CA+TgmoZ+=xojW1bLOTbaFdh7Jks5=QJC=ocj+yCdtiktrbenTg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: Abbreviated keys for Datum tuplesort  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: Re: Abbreviated keys for Datum tuplesort  (Peter Geoghegan <pg@heroku.com>)
Re: Re: Abbreviated keys for Datum tuplesort  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On Thu, Apr 2, 2015 at 5:34 PM, Peter Geoghegan <pg@heroku.com> wrote:
> I think it's explained by the pre-check for sorted input making the
> number of comparisons exactly n -1. As I pointed out to Tomas, if you
> put a single, solitary unsorted element at the end, the abbreviated
> version is then 8x faster (maybe that was in relation to a slightly
> different case, but the pattern is the same). So this case isn't an
> argument against datum abbreviation, or even abbreviation in general,
> but rather an argument against using strxfrm() in general (which for
> example the GCC docs strongly recommend for sorting lists of strings).
> It's a bad argument, IMV. This sort is already extremely fast.

OK, I see.

> The changes that Andrew
> took issue with are utterly insignificant.

Great.  Then you will be utterly indifferent to which version gets committed.

> Also, the changes that Andrew didn't mention are clearly appropriate.
> In particular, the comments on the SortKeys variable being used by
> every case except the hash case and datum case should still be updated
> to reflect that that's only true for the hash case now.

On that point, I agree.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: TABLESAMPLE patch
Следующее
От: Robert Haas
Дата:
Сообщение: Re: What exactly is our CRC algorithm?