From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Selectivity estimation for intarray |
Date: | 2015-04-29 10:48:42 |
Message-ID: | CAPpHfdssY+qEPDCOvxx-b4LP3ybR+qS04M6-ARgGKNFk3FrFow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hackers,
currently built-in &&, @>, <@ array operators have selectivity estimations
while same operator in intarray contrib haven't them. Problem is that
operators in intarray contrib still use contsel and contjoinsel functions
for selectivity estimation even when built-in operators receive their
specific selectivity estimations.
Attached patch adds selectivity estimation functions to &&, @>, <@
operators in intarray contrib. In order to have less code duplication they
are just wrappers over built-in selectivity estimation functions.
However, I faced a problem of migration scripts. Currently, ALTER OPERATOR
can only change owner and schema of operator not operator parameters
themselves. Change pg_operator directly is also not an option. At first, it
would be kludge. At second, in order to correctly find corresponding
operator in pg_operator migration script need to know schema where
extension is installed. But it can't refer @extschema@ because extension is
relocatable.
My proposal is to let ALTER OPERATOR change restrict and join selectivity
functions of the operator. Also it would be useful to be able to change
commutator and negator of operator: extension could add commutators and
negators in further versions. Any thoughts?
------
With best regards,
Alexander Korotkov.
Attachment | Content-Type | Size |
---|---|---|
intarray-sel-1.patch | application/octet-stream | 4.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-29 12:01:36 | Re: shared_libperl, shared_libpython |
Previous Message | Sawada Masahiko | 2015-04-29 07:38:45 | Re: Proposal: knowing detail of config files via SQL |