Planner decisions - Mailing list pgsql-general

From Wappler, Robert
Subject Planner decisions
Date
Msg-id C8E2DAF0E663A948840B04023E0DE32A02A22C91@w2k3server02.de.ophardt.com
Whole thread Raw
Responses Re: Planner decisions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Hi,

Attached is a query and its corresponding plan, where sorting of the CTE
acts seems to be the bottle neck. It is a real execution plan captured
with the auto_explain module.

The query is recursive. In each iteration CTE acts is sorted again,
which is obviously quite expensive for about 24000 rows and the same
number of iterations.

So I tried to put the ordering over the keys (d_id, activation_count)
into the CTE definition itself. This is honoured, when evaluating the
CTE but not for the iteration, where the CTE acts is still sorted again.
I cannot see a reason for this. A simple CTE scan with filter condition
should be enough.

Removing the order by from the definition of the CTE has absolutely no
impact on the performance, which is quite obvious regarding the number
of iterations. Further it has no impact on the query plan at all. It
only removes the sort node from the CTE acts node.

Do I miss something which would make the plan incorrect or is the
planner just not intelligent enough to recognize that a table is sorted
by the desired keys?

I hope the attachments prevent outlook from destroying any text
formatting.

Thanks in advance
--
Regards,
Robert


Attachment

pgsql-general by date:

Previous
From: Vincenzo Romano
Date:
Subject: [WISHLIST] EXECUTE SPRINTF
Next
From: Howard Rogers
Date:
Subject: Re: Full Text Search dictionary issues