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

From Itagaki Takahiro
Subject Re: texteq/byteaeq: avoid detoast [REVIEW]
Date
Msg-id AANLkTinXDJ-sQJNAYXRbF4B=msN4MzLMU2GLHUGcFBEi@mail.gmail.com
Whole thread Raw
In response to Re: texteq/byteaeq: avoid detoast [REVIEW]  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: texteq/byteaeq: avoid detoast [REVIEW]  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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.

> I did similar idea to represent security label on user tables for row
> level security in the v8.4/9.0 based implementation. Because a small
> number of security labels are shared by massive tuples, it is waste of
> space if we have all the text data being toasted individually, not only
> performance loss in toast/detoast.

It looks the same issue as large object rather than the discussion here.
We have vacuumlo in contrib to solve the issue. So, we could have
vacuumlo-like special sweeping logic for the security label table.

-- 
Itagaki Takahiro


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: texteq/byteaeq: avoid detoast [REVIEW]
Next
From: Fujii Masao
Date:
Subject: Re: pg_basebackup for streaming base backups