Re: Postgres 9.1: Adding rows to table causing too much latency in other queries

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: sushant354(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgres 9.1: Adding rows to table causing too much latency in other queries
Date: 2011-12-19 17:08:23
Message-ID: CABRT9RDGsPhsrGG66osjZo=6vEniA3bJkqSAP7YNowhD4auLAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 19, 2011 at 17:30, Sushant Sinha <sushant354(at)gmail(dot)com> wrote:
> This never happened earlier with postgres 9.0 Is there a known issue
> with Postgres 9.1? Or how to report this problem?

What *did* change in 9.1 is that there's new GIN cost estimation in
the planner. If you do EXPLAIN ANALYZE for your queries, do the plans
differ for 9.0 or 9.1? E.g. doing an index scan instead of a seq scan
or vice versa.

> The query uses the gin index and the tsearch ranking function
> ts_rank_cd.

Another thought -- have you read about the GIN "fast updates" feature?
This existed in 9.0 too. Instead of updating the index directly, GIN
appends all changes to a sequential list, which needs to be scanned in
whole for read queries. The periodic autovacuum process has to merge
these values back into the index.

Maybe the solution is to tune autovacuum to run more often on the table.

http://www.postgresql.org/docs/9.1/static/gin-implementation.html

Regards,
Marti

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2011-12-19 17:09:48 Re: Page Checksums
Previous Message Nikhil Sontakke 2011-12-19 17:07:02 Re: Review: Non-inheritable check constraints