| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Size of Path nodes |
| Date: | 2015-12-05 18:45:36 |
| Message-ID: | CAM-w4HPhogshh_hCEJrQE3otvSZBPg+_zoP7Vd9vsRBWtbCcmg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Dec 5, 2015 at 5:35 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The planner does not
> normally[1] use the same path type to represent two fundamentally different
> execution plans with enormously different cost estimates
Eh, this is a typical object modelling dilemma. There are lots of
different path types and many of them share a lot of properties but
depending on which way you look at things different sets of them seem
to be the same thing. BitmapScan is very like a Seqscan and
MergeAppend is like Append but have different node types, but nodes
with Filters attached didn't become FilteredSeqScan and
FilteredIndexScan etc... I'm not sure which Parallel is more like and
it may be more convenient for the planner one way and other parts the
other.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2015-12-05 19:09:29 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |
| Previous Message | Robert Haas | 2015-12-05 18:43:29 | Re: Size of Path nodes |