From: | Matheus de Oliveira <matioli(dot)matheus(at)gmail(dot)com> |
---|---|
To: | Ivan Voras <ivoras(at)freebsd(dot)org> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: tsearch2, large data and indexes |
Date: | 2014-04-23 12:26:30 |
Message-ID: | CAJghg4+-hLoT2QrWzEm2jAtGx4d4sEQDXfu39QY7=G5DfgahdQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Apr 23, 2014 at 8:08 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:
> >> And here is the explain analyze: http://explain.depesz.com/s/4xm
> >> It clearly shows a bitmap index scan operation is immediately followed
> >> by a recheck operation AND that the recheck operation actually does
> >> something, because it reduces the number of records from 61 to 58
> >> (!!!).
> >
> >
> > That could be ordinary visibility checking, not qual rechecking.
>
> Visibility as in transaction-wise? It's not, this was the only client
> connected to the dev server, and the only transaction(s) happening.
I guess Jeff meant the visibility of tuples, in this case there may have 3
rows that are referenced by the index but are not visible to your current
transaction (they may be visible by other transaction or simple hasn't been
marked by VACUUM).
If you have no concurrent transactions, you can run VACUUM on your table,
run the query again and see if the row counts matches.
Best regards,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-04-23 13:00:11 | Re: tsearch2, large data and indexes |
Previous Message | Ivan Voras | 2014-04-23 11:08:25 | Re: tsearch2, large data and indexes |