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 &&, @>

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 >