Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Heikki Linnakangas
On 07/21/2015 07:28 PM, Alexander Korotkov wrote: On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote: In this version of patch it's not checked if variable is actually and int[] not query_int. See following test case. # create table test2 as (select '1'::query_int val from generate_seri

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Alexander Korotkov
On Tue, Jul 21, 2015 at 6:49 PM, Heikki Linnakangas wrote: > On 07/21/2015 03:44 PM, Alexander Korotkov wrote: > >> While Uriy is on vacation, I've revised this patch a bit. >> > > I whacked this around quite a bit, and I think it's in a committable state > now. But if you could run whatever test

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Heikki Linnakangas
On 07/21/2015 03:44 PM, Alexander Korotkov wrote: While Uriy is on vacation, I've revised this patch a bit. I whacked this around quite a bit, and I think it's in a committable state now. But if you could run whatever tests you were using before on this, to make sure it still produces the sam

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Alexander Korotkov
On Tue, Jul 21, 2015 at 5:14 PM, Teodor Sigaev wrote: > Some notices about code: > > 1 Near function transformOperator() there is wrong operator name "@<" > Fixed. > 2 int_query (and intquery) should be replaced to query_int to be > consistent with actual type name. At least where it's used as

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Teodor Sigaev
Some notices about code: 1 Near function transformOperator() there is wrong operator name "@<" 2 int_query (and intquery) should be replaced to query_int to be consistent with actual type name. At least where it's used as separate lexeme. 3 For historical reasons @@ doesn't commutate with itself

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-21 Thread Alexander Korotkov
Hi! While Uriy is on vacation, I've revised this patch a bit. On Tue, Jul 14, 2015 at 8:55 PM, Jeff Janes wrote: > Hi Uriy, > > This patch looks pretty good. > > The first line of intarray--1.1.sql mis-identifies itself as "/* > contrib/intarray/intarray--1.0.sql */" > Fixed. > The real file

Re: [HACKERS] Selectivity estimation for intarray with @@

2015-07-14 Thread Jeff Janes
On Tue, May 26, 2015 at 4:58 AM, Uriy Zhuravlev wrote: > Hello. > > Attached patch based on: > > http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com > > and adds selectivity estimation functions to @@ (port from tsquery). Now we > support &&, @>

[HACKERS] Selectivity estimation for intarray with @@

2015-05-26 Thread Uriy Zhuravlev
Hello. Attached patch based on: http://www.postgresql.org/message-id/capphfdssy+qepdcovxx-b4lp3ybr+qs04m6-arggknfk3fr...@mail.gmail.com and adds selectivity estimation functions to @@ (port from tsquery). Now we support &&, @>, <@ and @@. In addition it was written migration to version 1.1 intar

Re: [HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> For the specific cases you mention, perhaps it would be all right if we >> taught plancache.c to blow away *all* cached plans upon seeing any change >> in pg_operator; but that seems like a brute-force solution. > Agreed that it is

Re: [HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Alexander Korotkov writes: > > 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

Re: [HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Tom Lane
Oleg Bartunov writes: > Any chance to have this patch in 9.5 ? Many intarray users will be happy. Considering how desperately behind we are on reviewing/committing patches that were submitted by the deadline, I don't think it would be appropriate or fair to add on major new patches that came in m

Re: [HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Tom Lane
Alexander Korotkov writes: > 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?

Re: [HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Oleg Bartunov
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 wrote: > Hackers, > > currently built-in &&, @>, <@ array operators have selectivity estimations > while same operator in intarray contrib haven't them. Problem is that >

[HACKERS] Selectivity estimation for intarray

2015-04-29 Thread Alexander Korotkov
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