On Wed, Dec 4, 2013 at 4:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@heroku.com> writes: >> I guess I could write a proper patch to have code setting up a scankey >> also set a flag that indicated that it was acceptable to assume that >> the special built-in comparator would do fine. ... >> I'd be happy with a scheme with only one built-in comparator, and >> allowed a few types to be cataloged such that it was indicated that >> just using the "built-in" comparator was acceptable, knowledge that >> could be passed to _bt_compare via the scankey. I'm thinking of just >> int4, and maybe date and a few other such int4 "covariant" types. > > If what you're proposing is that we have a fast path that compares Datums > as Datums, I should think that that would work fine for int2 as well, > *and* for int8 on machines where int8 is pass-by-value. (Does anyone > still care much about PG's performance on 32-bit hardware?) We might > have to fool a bit with the fooGetDatum macros in some cases, eg > I think Int16GetDatum isn't careful about sign extension. Admittedly, > that might introduce an offsetting cost on some hardware, but I think > on most machines sign-extension isn't noticeably more expensive than > zero-extension.
Yeah, I think if we can make something like this work, it would be neat-o. Getting this working for int4 would be a good win, as Peter says, but getting it working for both int4 and int8 with the same code would be a significantly better one. -- 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
