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
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
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
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
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
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
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 &&, @>
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
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
* 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
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
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?
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,
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
14 matches
Mail list logo