| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at>, Greg Stark <gsstark(at)mit(dot)edu>, Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Path question |
| Date: | 2010-10-13 17:46:09 |
| Message-ID: | 29628.1286991969@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Another awkwardness of this patch is that it makes
> create_append_path() and consequently set_dummy_rel_pathlist() take an
> additional "root" argument. While there's nothing terribly
> unreasonable about this on its face, it's only necessary so that
> create_append_path() can call cost_sort(), which takes "root" but
> doesn't actually use it. I'm not sure whether it's better to leave
> this as-is or to remove the root argument from cost_sort().
Right offhand the cleanest answer to that seems to be to leave
create_append_path alone, and make a separate function named something
like create_ordered_append_path that handles the case where cost_sort
might be needed. I rather wonder if we don't want two separate
execution-time node types anyway, since what Append does seems
significantly different from Merge (and MergeAppend would be just a
misnomer).
I have to run off for a doctors appointment, will continue looking at
this patch when I get back.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jesper Krogh | 2010-10-13 17:59:48 | Re: Slow count(*) again... |
| Previous Message | Josh Berkus | 2010-10-13 17:38:39 | Re: SQL command to edit postgresql.conf, with comments |