Re: btree_gin and btree_gist for enums
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: emre@hasegeli.com, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-11-05T19:11:22Z
Lists: pgsql-hackers
On 11/05/2016 01:13 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.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
Commits
-
Add btree_gin support for enum types
- 4ad0f88c443c 10.0 landed
-
Add btree_gist support for enum types.
- f7946a92b689 10.0 landed
-
Use CallerFInfoFunctionCall with btree_gist for numeric types
- 4b1c68d63e86 10.0 landed
-
Add a direct function call mechanism using the caller's context.
- 29bf5016835a 10.0 landed
-
Add support for EUI-64 MAC addresses as macaddr8
- c7a9fa399d55 10.0 cited
-
Add an Assert that enum_cmp_internal() gets passed an FmgrInfo pointer.
- 6d493e1a0135 10.0 landed