pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Shaun Thomas <sthomas@leapfrogonline.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Confirmation of bad query plan generated by 7.4
Date: Tue, 13 Jun 2006 15:54:44 -0500
Message-ID: <448EDFC4.8F27.00A9.0@leapfrogonline.com> (raw)
In-Reply-To: <9119.1150222168@sss.pgh.pa.us>
References: <448EB053.8F27.00A9.0@leapfrogonline.com>
	<448EB053.8F27.00A9.0@leapfrogonline.com>
	<9119.1150222168@sss.pgh.pa.us>

>>> On 6/13/2006 at 1:09 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> I missed the part where you explain why you think this plan is
terrible?
> 412ms for what seems a rather expensive query doesn't sound so
awful.

Sorry, I based that statement on the estimated/actual disparity.  That
particular query plan is not terrible in its results, but look at the
estimates and how viciously the explain analyze corrects the values.

Here's an example:

   ->  Index Scan using idx_evt_dt on l_event_log e 
       (cost=0.00..2641742.75 rows=15752255 width=12)
       (actual time=0.034..229.641 rows=38923 loops=1)

rows=15752255 ?  That's over half the 27M row table.  As expected, the
*actual* match is much, much lower at 38923.  As it turns out, Marcin
was right.  Simply changing:

now() - interval '2 days'

to

'2006-06-11 15:30:00'

generated a much more accurate set of estimates.  I have to assume
that
7.4 is incapable of that optimization step.  Now that I know this, I
plan on modifying my stored proc to calculate the value before
inserting
it into the query.

Thanks!


-- 

Shaun Thomas
Database Administrator

Leapfrog Online 
807 Greenwood Street 
Evanston, IL 60201 
Tel. 847-440-8253
Fax. 847-570-5750
www.leapfrogonline.com


Confidentiality Note:

The document(s) accompanying this e-mail transmission, if any, and the
e-mail transmittal message contain information from Leapfrog Online
Customer Acquisition, LLC is confidential or privileged. The information
is intended to be for the use of the individual(s) or entity(ies) named
on this e-mail transmission message. If you are not the intended
recipient, be aware that any disclosure, copying, distribution or use of
the contents of this e-mail is prohibited. If you have received this
e-mail in error, please immediately delete this e-mail and notify us by
telephone of the error



view thread (19+ messages)  latest in thread

Message-ID: <448EDFC4.8F27.00A9.0@leapfrogonline.com>
Permalink:  ../448EDFC4.8F27.00A9.0@leapfrogonline.com/
Also on:    postgresql.org/message-id/448EDFC4.8F27.00A9.0@leapfrogonline.com

 · 

reply

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: sthomas@leapfrogonline.com, tgl@sss.pgh.pa.us
  Subject: Re: Confirmation of bad query plan generated by 7.4
  In-Reply-To: <448EDFC4.8F27.00A9.0@leapfrogonline.com>

* 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