Tom Raney wrote:
RELOPTINFO (tenk1): rows=1 width=244
path list:
SeqScan(tenk1) rows=1 cost=0.00..434.00
IdxScan(tenk1) rows=1 cost=0.00..583.25
pathkeys: ((tenk1.unique2, onek.unique2)) ---
cheapest startup path:
Tom Lane wrote:
Tom Raney [EMAIL PROTECTED] writes:
Why does the planner consider both input variations of each symmetric merge join? The
README says there is not a lot of difference between the two options. When
are there any differences?
The righthand side needs to support mark/restore,
Tom Raney [EMAIL PROTECTED] writes:
Why does the index scan for tenk1 include a path key from
onek.unique2? Is it implying an equivalence there?
bench=# explain select * from tenk1 JOIN onek ON
tenk1.unique2=onek.unique2;
Yes, for an example like that the planner knows that tenk1.unique2
Tom Lane wrote:
Tom Raney [EMAIL PROTECTED] writes:
Why does the index scan for tenk1 include a path key from
onek.unique2? Is it implying an equivalence there?
bench=# explain select * from tenk1 JOIN onek ON
tenk1.unique2=onek.unique2;
Yes, for an example like that the planner knows
Why does the planner consider both input variations of each symmetric merge join? The
README says there is not a lot of difference between the two options. When
are there any differences?
-Tom Raney
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Fri, 2008-09-05 at 11:21 -0700, Tom Raney wrote:
Why does the planner consider both input variations of each symmetric merge
join? The README says there is not a lot of difference between the two
options. When are there any differences?
-Tom Raney
Tom Raney [EMAIL PROTECTED] writes:
Why does the planner consider both input variations of each symmetric merge
join? The README says there is not a lot of difference between the two
options. When are there any differences?
The righthand side needs to support mark/restore, the left
I've been working on a client application (based on the Red Hat Visual
Explain tool) to display all plans the planner considers graphically and
it does that. But, the trace functionality in the planner is always on
(and thus, taking up cycles and resources) whether or not it is
requested by
Tom Raney [EMAIL PROTECTED] writes:
My question is: How would I let the planner know when a planner session
has been invoked by the explain command? If I can slip a flag into
PlannerInfo or PlannerGlobal, that would be perfect. But, I'm a bit
stuck on how to get explain context to that
