Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: otar shavadze <oshavadze(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists
Date: 2016-11-13 22:57:15
Message-ID: CAMkU=1zX=GJJ1Z25TmFZMhhqWi0skdpnA99TKXy2fXg=jrPJEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sat, Nov 12, 2016 at 5:33 PM, otar shavadze <oshavadze(at)gmail(dot)com> wrote:

> Tried
>
> OPERATOR(pg_catalog.@>)
>
>
> as Tom mentioned, but still, don't get fast performance when value does
> not existed in any array.
>

Did you build the correct index?

>
> Also "played" with many different ways, gin, gist indexes (gin with and
> without *gin__int_ops*) but, always, there was some situation, where
> search in array was slow.
>

Yes. There will always be some situation when the array search is slow.
Is that situation one that a specific person cares about? Hard to tell,
since you have not given us any additional useful information.

I don't know exactly, may be I am wrong, but what I understood after
> several day "trying", is that, I never will use arrays, with tables more
> than 500 000-1000 000 rows, because then searching in this array is
> somehow problematic.
>
> I rebuild my structure and added another table (instead of using array)
> and then used join's instead of searching in array.
>
> That's works perfectly, joining works fast as hell, even for several
> millions rows in each table.
>

"Properly" normalizing your data is a wonderful thing, no doubt about it,
if you are prepared to deal with the consequences of doing so. But not
everyone has that luxury. Which is why there is more than one way of doing
things.

Cheers,

Jeff

In response to

Browse pgsql-general by date

  From Date Subject
Next Message James Sewell 2016-11-13 23:04:44 Sequential parallel scan / agg
Previous Message aws backup 2016-11-13 21:33:45 Re: pg_dumpall: could not connect to database "template1": FATAL: