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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: B-Tree support function number 3 (strxfrm() optimization)
Дата
Msg-id CA+Tgmob4p4WGv-TdROhhsyUHTBY-8MXtRMQ3RNBWQPeH0REvJQ@mail.gmail.com
обсуждение исходный текст
Ответ на 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
On Thu, Sep 25, 2014 at 2:05 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Thu, Sep 25, 2014 at 9:21 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> The top issue on my agenda is figuring out a way to get rid of the
>> extra SortSupport object.
>
> Really? I'm surprised. Clearly the need to restart heap tuple copying
> from scratch, in order to make the datum1 representation consistent,
> rather than abandoning datum1 for storing abbreviated keys or pointers
> entirely is a very important aspect of whether or not we should change
> that. In turn, that's something that's going to (probably
> significantly) affect the worst case.
>
> Do you have an opinion on that?

I haven't looked at that part of the patch in detail yet, so... not
really.  But I don't see why you'd ever need to restart heap tuple
copying.  At most you'd need to re-extract datum1 from the tuples you
have already copied.  To find out how much that optimization buys, you
should use tuples with many variable-length columns (say, 50)
preceding the text column you're sorting on. I won't be surprised if
that turns out to be expensive enough to be worth worrying about, but
I have not benchmarked it.

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



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: jsonb format is pessimal for toast compression
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}