Re: UNION ALL has higher cost than inheritance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UNION ALL has higher cost than inheritance
Date: 2010-11-08 20:27:14
Message-ID: 29555.1289248034@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

BTW, one other point for the archives, before I forget it: it'd probably
also be wise to change the parser's output representation of set
operations. I think it should create a separate RTE entry corresponding
to each SetOperation node, similar to what we do for explicit JOIN
nodes. Then there is a clean representation for Vars referencing the
setop outputs: they can use the RT index of the SetOp RTE entry.
The current implementation is that all Vars in the upper query use the
RTI of the leftmost leaf query of the setop structure, which is really
bogus. First, that query doesn't necessarily output the same datatypes
as the upper setops do, so the datatypes shown by the Vars don't always
match the RTE they claim to refer to. (This is one reason why all of
the setop optimizations we do have tend to punt as soon as any datatype
changes occur.) Second, this design provides no good way to refer to
outputs of intermediate setops. I think we will *have* to fix that if
we want to make the planner's handling of these cases much smarter than
it is now.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Glaesemann 2010-11-08 20:37:50 Removing pgsql_tmp files
Previous Message Pavel Stehule 2010-11-08 20:21:55 Re: proposal: plpgsql - iteration over fields of rec or row variable