Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
От
Tom Lane
Тема
Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds
Дата
Msg-id
2529.1361636073@sss.pgh.pa.us
Ответ на
Re: BUG: endless lseek(.., SEEK_END) from select queries
on x64 builds (Heikki Linnakangas)
Список
Дерево обсуждения
BUG: endless lseek(.., SEEK_END) from select queries on x64 builds Markus Schulz <msc@antzsystem.de>
Re: BUG: endless lseek(.., SEEK_END) from select queries
on x64 builds Stephen Frost <sfrost@snowman.net>
Re: BUG: endless lseek(.., SEEK_END) from select queries
on x64 builds Heikki Linnakangas <hlinnakangas@vmware.com>
Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds Markus Schulz <msc@antzsystem.de>
Re: BUG: endless lseek(.., SEEK_END) from select queries
on x64 builds Heikki Linnakangas <hlinnakangas@vmware.com>
Re: BUG: endless lseek(.., SEEK_END) from select queries on x64 builds Tom Lane <tgl@sss.pgh.pa.us>
Heikki Linnakangas 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
В списке pgsql-performance по дате отправления
От: Heikki Linnakangas
Дата: