Re: Selectivity estimation for intarray with @@

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Uriy Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Selectivity estimation for intarray with @@
Date: 2015-07-21 15:38:43
Message-ID: CAPpHfdusKwuLxv6SJixFT8XV5S578VH2iGHR2=HzE_PFiTkfLA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 21, 2015 at 5:14 PM, Teodor Sigaev <teodor(at)sigaev(dot)ru> 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 separate
> lexeme.
>

Fixed.

> 3 For historical reasons @@ doesn't commutate with itself, it has a
> commutator ~~. Patch assumes that @@ is self-commutator, but ~~ will use
> 'contsel' as a restrict estimation. Suppose, we need to declare ~~ as
> deprecated and introduce commutating @@ operator.

I think deprecating ~~ is a subject of separate patch. I fixed patch
behavior in the different way. @@ and ~~ are now handled by the same
function. The function handles "var @@ const" and "const ~~ var", but
doesn't handle "const @@ var" and "var ~~ const". It determines the case
by type of variable: it should be int[].

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
intarray_sel-3.patch application/octet-stream 36.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2015-07-21 15:49:23 Re: Selectivity estimation for intarray with @@
Previous Message Andres Freund 2015-07-21 15:26:29 Re: [PATCH] postgres_fdw extension support