pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnakangas@vmware.com>
Cc: Markus Schulz <msc@antzsystem.de>
Cc: pgsql-performance@postgresql.org
Subject: Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
Date: Sat, 23 Feb 2013 11:14:33 -0500
Message-ID: <2529.1361636073@sss.pgh.pa.us> (raw)
In-Reply-To: <5128E632.2040209@vmware.com>
References: <201302220925.26460.msc@antzsystem.de>
	<5127741D.6090907@vmware.com>
	<201302221910.25271.msc@antzsystem.de>
	<5128E632.2040209@vmware.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Heikki Linnakangas <hlinnakangas@vmware.com> writes:
> You can take the query, replace the ? parameter markers with $1, $2, and 
> so forth, and explain it with psql like this:

> prepare foo (text) as select * from mytable where id = $1;
> explain analyze execute foo ('foo');

> On 9.2, though, this will explain the specific plan for those 
> parameters, so it might not be any different from what you already 
> EXPLAINed.

You can tell whether you're getting a generic or custom plan by noting
whether the explain output contains $n symbols or the values you put in.
In 9.2, the first five attempts will always produce custom plans, but
on the sixth and subsequent attempts you will get a generic plan, if
the plancache logic decides that it's not getting any benefit out of
custom plans.  Here's a trivial example:

regression=# prepare foo(int) as select * from tenk1 where unique1 = $1;
PREPARE
regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = 42)
(2 rows)

regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = 42)
(2 rows)

regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = 42)
(2 rows)

regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = 42)
(2 rows)

regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = 42)
(2 rows)

regression=# explain execute foo(42);
                                 QUERY PLAN                                  
-----------------------------------------------------------------------------
 Index Scan using tenk1_unique1 on tenk1  (cost=0.29..8.30 rows=1 width=244)
   Index Cond: (unique1 = $1)
(2 rows)

It's switched to a generic plan after observing that the custom plans
weren't any cheaper.  Once that happens, subsequent attempts will use
the generic plan.  (Of course, in a scenario where the custom plans do
provide a benefit, it'll keep using those.)

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (6+ messages)

Message-ID: <2529.1361636073@sss.pgh.pa.us>
Permalink:  ../2529.1361636073@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2529.1361636073@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, hlinnakangas@vmware.com, msc@antzsystem.de
  Subject: Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
  In-Reply-To: <2529.1361636073@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