Re: texteq/byteaeq: avoid detoast [REVIEW] - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: texteq/byteaeq: avoid detoast [REVIEW]
Date
Msg-id AANLkTikbYnSHyrp_1eonqOMMgnj8YHjJQaH40G9ak8Am@mail.gmail.com
Whole thread Raw
In response to Re: texteq/byteaeq: avoid detoast [REVIEW]  (Itagaki Takahiro <itagaki.takahiro@gmail.com>)
Responses Re: texteq/byteaeq: avoid detoast [REVIEW]  (Noah Misch <noah@leadboat.com>)
Re: texteq/byteaeq: avoid detoast [REVIEW]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jan 17, 2011 at 09:13, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> 2011/1/17 KaiGai Kohei <kaigai@ak.jp.nec.com>:
>> Are you talking about an idea to apply toast id as an alternative key?
>
> No, probably. I'm just talking about whether "diff -q A.txt B.txt" and
> "diff -q A.gz  B.gz" always returns the same result or not.
>
> ... I found it depends on version of gzip. So, if we use such logic,
> we cannot improve toast compression logic because the data is migrated
> by pg_upgrade.

Yeah, that might be a bad tradeoff.

I wonder if we can trust the *equality* test, but not the inequality?
E.g. if compressed(A) == compressed(B) we know they're the same, but
if compressed(A) != compressed(B) we don't know they're not they still
might be.

I guess with two different versions or even completely different
algorithms we could end up with exactly the same compressed value for
different plaintexts (it's not a cryptographic hash after all), so
that's probably not an acceptable comparison either.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Include WAL in base backup
Next
From: Fujii Masao
Date:
Subject: Re: pg_basebackup for streaming base backups