Skip site navigation (1) Skip section navigation (2)

Re: slow seqscan

From: Nick Barr <nicky(at)chuckie(dot)co(dot)uk>
To: Edoardo Ceccarelli <eddy(at)axa(dot)it>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: slow seqscan
Date: 2004-04-21 07:47:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Edoardo Ceccarelli wrote:

> My first post to this list :)
> Scenario:
> I have a database used only with search queries with only one table that
> holds about 450.000/500.000 records.
> The table is well indexed so that most of the queries are executed with
> index scan but since there is a big text field in the table (360chars)
> some search operation (with certain filters) ends up with seq scans.
> This table is not written during normal operation: twice per week there
> is a batch program that insert about 35.000 records and updates another
> 40.000.
> last friday morning, after that batch has been executed, the database 
> started responding really slowly to queries (expecially seq scans), 
> after a "vacuum full analize" things did get something better.
> Yesterday the same: before the batch everything was perfect, after 
> every query was really slow, I've vacuum it again and now is ok.
> Since now the db was working fine, it's 4 month's old with two updates 
> per week and I vacuum about once per month.
> I am using version 7.3 do I need to upgrade to 7.4? also, I was thinking
> about setting this table in a kind of  "read-only" mode to improve
> performance, is this possible?
> Thank you for your help
> Edoardo Ceccarelli
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend

In general we are going to need more information, like what kind of 
search filters you are using on the text field and an EXPLAIN ANALYZE. 
But can you try and run the following, bearing in mind it will take a 
while to complete.

REINDEX TABLE <table_name>

 From what I remember there were issues with index space not being 
reclaimed in a vacuum. I believe this was fixed in 7.4. By not 
reclaiming the space the indexes grow larger and larger over time, 
causing PG to prefer a sequential scan over an index scan (I think).

Hope that helps


In response to

  • slow seqscan at 2004-04-21 07:17:23 from Edoardo Ceccarelli


pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2004-04-21 07:52:55
Subject: Re: slow seqscan
Previous:From: Edoardo CeccarelliDate: 2004-04-21 07:17:23
Subject: slow seqscan

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group