Index Only Scan support for cube
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t36765psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 06:38 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t36765_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t36765_1 && git checkout t36765_1Patchset v1 (message #1) is on t36765_1
Hi, hackers!
Here's a small patch that implements fetch function necessary for
Index Only Scans that use cube data type.
I reuse function g_cube_decompress() instead of creating new function
g_cube_fetch().
Essentially, they both have to detoast data.
How do you think, is it better to create a shallow copy of
g_cube_decompress instead?
Any other suggestions on the functionality?
This
CREATE TABLE SOMECUBES AS SELECT CUBE(X,X+1) C FROM GENERATE_SERIES(1,100) X;
CREATE INDEX SOMECUBES_IDX ON SOMECUBES USING GIST(C);
SET ENABLE_SEQSCAN = FALSE;
EXPLAIN (COSTS OFF ) SELECT C FROM SOMECUBES WHERE C<@CUBE(30,40);
now produces
Index Only Scan using somecubes_idx on somecubes
Index Cond: (c <@ '(30),(40)'::cube)
instead of
Index Scan using somecubes_idx on somecubes
Index Cond: (c <@ '(30),(40)'::cube)
Best regards, Andrey Borodin, Octonica.
Hi hackers!
23 мая 2017 г., в 14:53, Andrew Borodin <borodin@octonica.com> написал(а):
Here's a small patch that implements fetch function necessary for
Index Only Scans that use cube data type.
Tom Lane have just commited d3a4f89 (Allow no-op GiST support functions to be omitted) Thanks, Tom! : )
"Index Only Scan support for cube" patch now is obsolete. I'm working on another similar patch for contribs to support GiST IOS and remove no-op support functions.
Best regards, Andrey Borodin.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Sep 20, 2017 at 8:26 AM, Andrey Borodin <x4mmm@yandex-team.ru>
wrote:
Hi hackers!
23 мая 2017 г., в 14:53, Andrew Borodin <borodin@octonica.com>
написал(а):
Here's a small patch that implements fetch function necessary for
Index Only Scans that use cube data type.Tom Lane have just commited d3a4f89 (Allow no-op GiST support functions to
be omitted) Thanks, Tom! : )
"Index Only Scan support for cube" patch now is obsolete. I'm working on
another similar patch for contribs to support GiST IOS and remove no-op
support functions.
Good.
BTW, some strangeness of g_cube_decompress() catch my eye. It compares
results of two evaluations of same expression DatumGetNDBOXP(entry->key).
NDBOX *key = DatumGetNDBOXP(entry->key);
if (key != DatumGetNDBOXP(entry->key))
In fact it's correct, because it compares results of two detoasting. If
datum isn't toasted then results would be the same. And if data is toasted
then results would be two different allocation of detoasted datum.
However, we do extra detoasting here.
For example, see gbt_var_decompress(). There is no extra detoasting here.
GBT_VARKEY *key = (GBT_VARKEY *) PG_DETOAST_DATUM(entry->key);
if (key != (GBT_VARKEY *) DatumGetPointer(entry->key))
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company