Selectivity estimation for intarray

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

Responses

Browse pgsql-hackers by date

  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