Re: tsearch2, large data and indexes

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

In response to

Browse pgsql-performance by date

  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