On Wed, Dec 7, 2011 at 10:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > There's some stuff that's debatable according to this criterion --- in > particular, I wondered whether it'd be worth having a fast path for > bttextcmp, especially if we pre-tested the collate_is_c condition and > had a separate version that just hardwired the memcmp code path. (The > idea of doing that was one reason I insisted on collation being known at > the setup step.) 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). >> Are you planning to do anything about #2 or #3? > > I am willing to do #2, but not right now; I feel what I need to do next > is go review SPGist. Yeah, makes sense. That one seems likely to be a challenge to absorb. > I don't believe that #2 blocks progress on #3 > anyway. I think #3 is in Peter's court, or yours if you want to do it. > > (BTW, I agree with your comments yesterday about trying to break down > the different aspects of what Peter did, and put as many of them as we > can into the non-inlined code paths.) Cool. Peter, can you rebase your patch and integrate it into the sortsupport framework that's now committed? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
