Re: Postgres 9.1: Adding rows to table causing too much latency in other queries - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: Postgres 9.1: Adding rows to table causing too much latency in other queries
Date
Msg-id CABRT9RDGsPhsrGG66osjZo=6vEniA3bJkqSAP7YNowhD4auLAg@mail.gmail.com
Whole thread Raw
In response to Postgres 9.1: Adding rows to table causing too much latency in other queries  (Sushant Sinha <sushant354@gmail.com>)
Responses Re: Postgres 9.1: Adding rows to table causing too much latency in other queries  (Sushant Sinha <sushant354@gmail.com>)
Re: Postgres 9.1: Adding rows to table causing too much latency in other queries  (Jesper Krogh <jesper@krogh.cc>)
Re: Postgres 9.1: Adding rows to table causing too much latency in other queries  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Dec 19, 2011 at 17:30, Sushant Sinha <sushant354@gmail.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


pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Review: Non-inheritable check constraints
Next
From: Andres Freund
Date:
Subject: Re: Page Checksums