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
comparisonfunctions 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
