On 08/02/2013 03:22 AM, Scott Marlowe wrote:
> On Thu, Aug 1, 2013 at 5:44 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> Scott Marlowe <scott.marlowe@xxxxxxxxx> writes:
>>> I am running 8.4.15 and can try 8.4.17 if some patch has been applied
>>> to it to address this issue. I just want to know should I
>>> A: upgrade to 8.4.17
>>> or
>>> B: create a self contained test case.
>> A quick look at the release notes shows no planner fixes in 8.4.16 or
>> 8.4.17, so it would be rather surprising if (A) helps.
> OK. I was doing some initial testing and if I select out the 4 columns
> into a test table the query runs fast. If I select all the columns
> into a test table it runs slow, so it appears table width affects
> this. Will have more to report tomorrow on it.
I don't know what your query is, but here's one I was working on
yesterday that shows the problem. It may not be the smallest test case
possible, but it works.
EXPLAIN ANALYZE
WITH RECURSIVE
x (start_time) AS
(
SELECT generate_series(1, 1000000)
),
t (time, timeround) AS
(
SELECT time, time - time % 900000 AS timeround
FROM (SELECT min(start_time) AS time FROM x) AS tmp
UNION ALL
SELECT time, time - time % 900000
FROM (SELECT (SELECT min(start_time) AS time
FROM x
WHERE start_time >= t.timeround + 900000)
FROM t
WHERE t.time IS NOT NULL OFFSET 0
) tmp
)
SELECT count(*) FROM t WHERE time IS NOT NULL;
If you remove the OFFSET 0, you'll see two more subplans (because "time"
is referenced three times). The difference is much more noticeable if
you make the x CTE its own table.
Vik
PS: This query is emulating a LooseIndexScan.
http://wiki.postgresql.org/wiki/Loose_indexscan
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
