Re: B-Tree support function number 3 (strxfrm() optimization)
От | Robert Haas |
---|---|
Тема | Re: B-Tree support function number 3 (strxfrm() optimization) |
Дата | |
Msg-id | CA+TgmobxT9=NZnZBLEWAh2spErbwpAtjT=eEY9VHOfarvOV92g@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 3:17 PM, Peter Geoghegan <pg@heroku.com> wrote: >> 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. > > Sorry, but I don't follow. I don't think the pertinent question is if > it's a noticeable cost. I think the pertinent question is if it's > worth it. Doing something about it necessitates a lot of extra memory > access. Not doing something about it hardly affects the amount of > memory access required, perhaps not at all. I think you're mincing words. If you go back and fix datum1, you'll spend a bunch of effort doing that. If you don't, you'll pay a cost on every comparison to re-find the relevant column inside each tuple. You can compare those costs in a variety of cases, including the one I mentioned, where the latter cost will be relatively high. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: