From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | amborodin(at)acm(dot)org, Andrew Borodin <borodin(at)octonica(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow GiST opcalsses without compress\decompres functions |
Date: | 2017-05-28 17:22:27 |
Message-ID: | 20118.1495992147@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Borodin <borodin(at)octonica(dot)com> writes:
> Maybe we should make compress\decompress functions optional?
1. You'll need to adjust the documentation (gist.sgml) not just the code.
2. If compress/decompress are omitted, then we could support index-only
scans all the time, that is a no-op fetch function would work. The
patch should cover that interaction too.
3. Personally I wouldn't bother with the separate compressed[] flags,
just look at OidIsValid(giststate->compressFn[i].fn_oid).
4. I don't think you thought very carefully about the combinations
where only one of the two functions is supplied. I can definitely
see that compress + no decompress could be sensible. Less sure
about the other case, but why not allow it? We could just say that
an omitted function is taken to represent a no-op transformation.
Please add this to the next commitfest.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-05-28 17:49:08 | Re: execGrouping.c limit on work_mem |
Previous Message | Erik Rijkers | 2017-05-28 10:44:49 | Re: logical replication - still unstable after all these months |