Re: Selectivity estimation for intarray - Mailing list pgsql-hackers

From Oleg Bartunov
Subject Re: Selectivity estimation for intarray
Date
Msg-id CAF4Au4wd9MUfquxsu7boX6_g1-r6qUhCziZhvSn9d2gUnwLy-g@mail.gmail.com
Whole thread Raw
In response to Selectivity estimation for intarray  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Selectivity estimation for intarray
List pgsql-hackers
Any chance to have this patch in 9.5 ? Many intarray users will be happy.

On Wed, Apr 29, 2015 at 1:48 PM, Alexander Korotkov <aekorotkov@gmail.com> wrote:
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.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: shared_libperl, shared_libpython
Next
From: Stephen Frost
Date:
Subject: Re: pg_rewind test race condition..?