Re: Inlining comparators as a performance optimisation
| От | Robert Haas |
|---|---|
| Тема | Re: Inlining comparators as a performance optimisation |
| Дата | |
| Msg-id | CA+Tgmob1BE2ACXTFRtH9RFqgqc8UjK9mu6ccyEen-XD+pai5=Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Inlining comparators as a performance optimisation (Peter Geoghegan <peter@2ndquadrant.com>) |
| Ответы |
Re: Inlining comparators as a performance optimisation
|
| Список | pgsql-hackers |
On Wed, Dec 7, 2011 at 10:58 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 7 December 2011 15:15, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Dec 7, 2011 at 10:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> But it would still have to be prepared for detoasting, >>> so in the end I was unenthused. Anyone who feels like testing could try >>> to prove me wrong about it though. >> >> I think that'd definitely be worth investigating (although I'm not >> sure I have the time to do it myself any time real soon). > > I'll at least take a look at it. Sorting text is a fairly common case. > I'm not hugely enthused about spending too much time on work that will > only be useful if collate_is_c. Well, text_pattern_ops is not exactly an uncommon case, but sure. And there might be some benefit for other collations, too. >> Cool. Peter, can you rebase your patch and integrate it into the >> sortsupport framework that's now committed? > > Yes, I'd be happy to, though I don't think I'm going to be getting > around to it this side of Friday. Since it isn't a blocker, I assume > that's okay. Sounds fine to me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: