From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sean Leach <sleach@wiggum.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Weird issue with planner choosing seq scan
Date: Sun, 24 Feb 2008 14:10:25 -0500
Message-ID: <6253.1203880225@sss.pgh.pa.us> (raw)
In-Reply-To: <7ECB45D8-33ED-45FC-A0DA-D3DE25B6CC8E@wiggum.com>
References: <F836C829-D69F-4FA3-966C-002E715BF26F@wiggum.com>
<5289.1203875431@sss.pgh.pa.us>
<7ECB45D8-33ED-45FC-A0DA-D3DE25B6CC8E@wiggum.com>
Sean Leach <sleach@wiggum.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 c.res_id=r.id AND stamp > (SELECT current_timestamp - interval
'1 day') AND r.rtype='udns' AND r.location=1 GROUP BY node;
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, sleach@wiggum.com
Subject: Re: Weird issue with planner choosing seq scan
In-Reply-To: <6253.1203880225@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox