Re: texteq/byteaeq: avoid detoast [REVIEW]

From: Noah Misch <noah(at)leadboat(dot)com>
To: Jim Nasby <jim(at)nasby(dot)net>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Andy Colson <andy(at)squeakycode(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: texteq/byteaeq: avoid detoast [REVIEW]
Date: 2011-01-17 21:13:12
Message-ID: 20110117211312.GA14843@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2011-01-17 21:23:31 Re: WIP: RangeTypes
Previous Message Jeff Davis 2011-01-17 21:09:26 Re: WIP: RangeTypes