Re: sortsupport for text
От | Peter Geoghegan |
---|---|
Тема | Re: sortsupport for text |
Дата | |
Msg-id | CAEYLb_VfBeWMQkXRgmV4PNiGFfjLaVT9unsam6Y=-OZks_kPbA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sortsupport for text (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: sortsupport for text
|
Список | pgsql-hackers |
On 14 June 2012 17:35, Robert Haas <robertmhaas@gmail.com> wrote: > The problem with pre-detoasting to save comparison cycles is that you > can now fit many, many fewer tuples in work_mem. There might be cases > where it wins (for example, because the entire data set fits even > after decompressing everything) but in most cases it seems like a > loser. If I had to guess, I'd say you're probably right about that - optimising sorting toasted text doesn't seem like a terribly sensible use of your time. What about the strxfrm suggestion of Greg's? You might find that the added benefit of being able to avail of a highly optimised strcmp() tipped the balance in favour of that idea, beyond the simple fact that there's only a linear number of what you might loosely call "strcoll_l units of work" rather than as many as O(n ^ 2). Furthermore, I'd speculate that if you were to interlace the strxfrm() calls with copying each text string, somewhere like within a specialised datumCopy(), that would make the approach more efficient still, as you specify a location for the blob in the just-palloc()'d leading-key private memory directly, rather than just using memcpy. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: