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

Re: Weird issue with planner choosing seq scan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sean Leach <sleach(at)wiggum(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Weird issue with planner choosing seq scan
Date: 2008-02-24 19:10:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Sean Leach <sleach(at)wiggum(dot)com> writes:
> Now - here is prod:

> db=> select count(1) from u_counts;
>    count
> ---------
>   3292215
> (1 row)

>           ->  Seq Scan on u_counts c  (cost=0.00..444744.45  
> rows=1106691 width=4) (actual time=1429.996..7893.178 rows=1036015  
> loops=1)
>                 Filter: (stamp > (now() - '1 day'::interval))

Given that this scan actually is selecting about a third of the table,
I'm not sure that the planner is doing the wrong thing.  It's hard to
see how an indexscan would be an improvement.

[ thinks for a bit... ]  Actually, the problem might be the 3M
executions of now() and interval subtraction that you get in the seqscan
case.  What results do you get if you write it with a sub-select like this:

explain analyze SELECT node,count(*) AS counts FROM u_counts  
c,res r WHERE AND stamp > (SELECT current_timestamp - interval  
'1 day') AND r.rtype='udns' AND r.location=1 GROUP BY node;

			regards, tom lane

In response to


pgsql-performance by date

Next:From: Sean LeachDate: 2008-02-24 20:28:17
Subject: Re: Weird issue with planner choosing seq scan
Previous:From: Tom LaneDate: 2008-02-24 18:57:48
Subject: Re: LISTEN / NOTIFY performance in 8.3

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