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
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 |