Re: Index Only Scan support for cube

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Andrew Borodin <amborodin(at)acm(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Index Only Scan support for cube
Date: 2017-09-20 08:49:35
Message-ID: CAPpHfdsHTEaoz=cWv3M-50nc+qt9TGCs-dVsz+wTL_84M2RQfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 20, 2017 at 8:26 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
wrote:

> Hi hackers!
> > 23 мая 2017 г., в 14:53, Andrew Borodin <borodin(at)octonica(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-09-20 08:55:43 Re: Error: dsa_area could not attach to a segment that has been freed
Previous Message Rafia Sabih 2017-09-20 08:33:25 Re: Partition-wise join for join between (declaratively) partitioned tables