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)
|
Список | 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 по дате отправления: