| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, David Steele <david(at)pgmasters(dot)net>, Ildus Kurbangaliev <i(dot)kurbangaliev(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Custom compression methods |
| Date: | 2021-02-11 14:47:02 |
| Message-ID: | CA+TgmobFEhN31acEgf9MAw_ax0cxx22V+yWbx1wRgxcDU+NpmA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 11, 2021 at 7:36 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> W.R.T the attached patch, In HeapTupleHeaderGetDatum, we don't even
> attempt to detoast if there is no external field in the tuple, in POC
> I have got rid of that check, but I think we might need to do better.
> Maybe we can add a flag in infomask to detect whether the tuple has
> any compressed data or not as we have for detecting the external data
> (HEAP_HASEXTERNAL).
No. This feature isn't close to being important enough to justify
consuming an infomask bit.
I don't really see why we need it anyway. If array construction
already categorically detoasts, why can't we do the same thing here?
Would it really cost that much? In what case? Having compressed values
in a record we're going to store on disk actually seems like a pretty
dumb idea. We might end up trying to recompress something parts of
which have already been compressed.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2021-02-11 14:51:31 | Re: WIP: BRIN multi-range indexes |
| Previous Message | Bharath Rupireddy | 2021-02-11 14:44:37 | Re: Improvements and additions to COPY progress reporting |