| From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
|---|---|
| To: | Marti Raudsepp <marti(at)juffo(dot)org> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Subject: | Re: PoC: Partial sort |
| Date: | 2014-02-20 07:37:30 |
| Message-ID: | CAPpHfdvrhbv+gGbLDsDFJY9Ln1ei4M2WiGnRzuZUnGGW_cfKZQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Feb 13, 2014 at 1:54 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> I think the 1st patch now has a bug in initial_cost_mergejoin; you
> still pass the "presorted_keys" argument to cost_sort, making it
> calculate a partial sort cost, but generated plans never use partial
> sort. I think 0 should be passed instead. Patch attached, needs to be
> applied on top of partial-sort-basic-1 and then reverse-applied on
> partial-sort-merge-1.
>
It doesn't look so for me. Merge join doesn't find partial sort especially.
But if path with some presorted pathkeys will be accidentally selected then
partial sort will be used. See create_mergejoin_plan function. So, I think
this cost_sort call is relevant to create_mergejoin_plan. If we don't want
partial sort to be used in such rare cases then we should revert it from
both places. However, I doubt that it does any overhead, so we can leave it
as is.
------
With best regards,
Alexander Korotkov.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2014-02-20 08:17:42 | Re: Fwd: patch: make_timestamp function |
| Previous Message | Ashutosh Bapat | 2014-02-20 07:16:44 | Selecting large tables gets killed |