Re: btree_gin and btree_gist for enums

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: emre(at)hasegeli(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: btree_gin and btree_gist for enums
Date: 2016-11-05 19:11:22
Message-ID: 60fb708c-8b3c-1337-934e-c1bfe2afc539@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11/05/2016 01:13 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> On 11/05/2016 11:46 AM, Tom Lane wrote:
>>> That may be a good fix for robustness purposes, but it seems pretty horrid
>>> from an efficiency standpoint. Where is this call, and should we be
>>> modifying it to provide a flinfo?
>> I thought of providing an flinfo, but I couldn't see a simple way to do
>> it that would provide something much longer lived than the function
>> call, in which case it seemed a bit pointless. That's why I asked for
>> assistance :-)
> Hmm. The problem is that the intermediate layer in btree_gist (and
> probably btree_gin too, didn't look) does not pass through the
> FunctionCallInfo data structure that's provided by the GIST AM.
> That wasn't needed up to now, because none of the supported data types
> are complex enough that any cached state would be useful, but trying
> to extend it to enums exposes the shortcoming.
>
> We could fix this, but it would be pretty invasive since it would require
> touching just about every function in btree_gist/gin. Not entirely sure
> that it's worth it. On the other hand, the problem might well come up
> again in future, perhaps for a datatype where the penalty for lack of
> a cache is greater --- eg, it would be pretty painful to support
> record_cmp without caching. And the changes ought to be relatively
> mechanical, even if they are extensive.

Yeah. I think it's probably worth doing. btree_gin is probably a better
place to start because it's largely macro-ized.

I don't have time right now to do this. I'll try to get to it if nobody
else does over then next couple of months.

>
> BTW, this patch would be a great deal shorter if you made use of the
> work done in 40b449ae8. That is, you no longer need to replace the
> base extension script --- just add an update script and change the
> default version in the .control file. See fd321a1df for an example.

Oh, nice. My work was originally done in March, before this came in.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-11-05 20:05:34 Re: Mention column name in error messages
Previous Message Tom Lane 2016-11-05 18:13:52 Re: Mention column name in error messages