On Mon, Jan 17, 2011 at 02:36:56PM -0600, Jim Nasby wrote: > On Jan 17, 2011, at 9:22 AM, Noah Misch wrote: > > Just to be clear, the code already has these length tests today. This patch > > just moves them before the detoast. > > Any reason we can't do this for other varlena? I'm wondering if it makes more > sense to have some generic toast comparison functions that don't care what > the data in toast actually is...
We could not apply the optimization to varlenas generically. For example, bpchareq() ignores trailing white space during comparison, so "foo " = "foo ". It would work for biteq(), though I'm not sure how often large-scale varbits come up. numericeq() does not qualify, because you might have a NumericLong in a binary-upgraded table that would now become a NumericShort. So, there very well may be other places where we should apply the same optimization, but each one needs individual consideration. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
