On 19-12-2011 12:30, Sushant Sinha wrote:
I recently upgraded my postgres server from 9.0 to 9.1.2 and I am
finding a peculiar problem.I have a program that periodically adds rows
to this table using INSERT. Typically the number of rows is just 1-2
thousand when the table already has 500K
On Mon, Dec 19, 2011 at 17:30, Sushant Sinha sushant...@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
On Mon, 2011-12-19 at 19:08 +0200, Marti Raudsepp wrote:
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
On Mon, 2011-12-19 at 12:41 -0300, Euler Taveira de Oliveira wrote:
On 19-12-2011 12:30, Sushant Sinha wrote:
I recently upgraded my postgres server from 9.0 to 9.1.2 and I am
finding a peculiar problem.I have a program that periodically adds
rows
to this table using INSERT. Typically the
On 2011-12-19 18:08, Marti Raudsepp wrote:
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
Marti Raudsepp ma...@juffo.org writes:
On Mon, Dec 19, 2011 at 17:30, Sushant Sinha sushant...@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
Jesper Krogh jes...@krogh.cc writes:
I have to say that I consistently have to turn fastupdate off for
our heavily updated gin-indexes. The overall performance gain
may be measurable, but its not intolerable without. The spikes seen
from the applications, when cleanup happens. Either in the
