Re: Allowing GIN array_ops to work on anyarray - Mailing list pgsql-hackers

<div dir="ltr">This is awesome. I will build it to start using and testing it in my development environment. Thank you
somuch for making this change.<br /></div><br /><div class="gmail_quote"><div dir="ltr">On Thu, Aug 11, 2016 at 11:33
AMTom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>> wrote:<br /></div><blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In<br /><a
href="https://www.postgresql.org/message-id/15293.1466536829@sss.pgh.pa.us"rel="noreferrer"
target="_blank">https://www.postgresql.org/message-id/15293.1466536829@sss.pgh.pa.us</a><br/> I speculated that it
mightnot take too much to replace all the variants<br /> of GIN array_ops with a single polymorphic opclass over
anyarray.<br/> Attached is a proposed patch that does that.<br /><br /> There are two bits of added functionality
neededto make this work:<br /><br /> 1. We need to abstract the storage type.  The patch does this by teaching<br />
catalog/index.cto recognize an opckeytype specified as ANYELEMENT with an<br /> opcintype of ANYARRAY, and doing the
arrayelement type lookup at index<br /> creation time.<br /><br /> 2. We need to abstract the key comparator.  The
patchdoes this by<br /> teaching gin/ginutil.c that if the opclass omits a GIN_COMPARE_PROC,<br /> it should look up
thedefault btree comparator for the index key type.<br /><br /> Both of these seem to me to be reasonable
general-purposebehaviors with<br /> potential application to other opclasses.<br /><br /> In the aforementioned message
Iworried that a core opclass defined this<br /> way might conflict with user-built opclasses for specific array
types,<br/> but it seems to work out fine without any additional tweaks: CREATE INDEX<br /> already prefers an exact
matchif it finds one, and only falls back to<br /> matching anyarray when it doesn't.  Also, all the replaced opclasses
are<br/> presently default for their types, which means that pg_dump won't print<br /> them explicitly in CREATE INDEX
commands,so we don't have a dump/reload<br /> or pg_upgrade hazard from them disappearing.<br /><br /> A potential
downsideis that for an opclass defined this way, we add a<br /> lookup_type_cache() call to each initGinState() call. 
That'sbasically<br /> just a single dynahash lookup once the caches are populated, so it's not<br /> much added cost,
butconceivably it could be measurable in bulk insert<br /> operations.  If it does prove objectionable my inclination
wouldbe to<br /> look into ways to avoid the repetitive function lookups of initGinState,<br /> perhaps by letting it
cachethat stuff in the index's relcache entry.<br /><br /> I'll put this on the September commitfest docket.<br /><br
/>                        regards, tom lane<br /><br /></blockquote></div>