Re: WITH ORDINALITY planner improvements - Mailing list pgsql-hackers

> > However it occurs to me that the plan isn't ideal:
> >
> > postgres=# explain select * from generate_series(1,10) with ordinality
> > as a(a,o) natural full outer join generate_series(1,5) with ordinality
> > as b(b,o) ;
> >                                       QUERY PLAN
> > ----------------------------------------------------------------------
> > -----------------  Merge Full Join  (cost=119.66..199.66 rows=5000
> > width=24)
> >    Merge Cond: (a.o = b.o)
> >    ->  Sort  (cost=59.83..62.33 rows=1000 width=12)
> >          Sort Key: a.o
> >          ->  Function Scan on generate_series a  (cost=0.00..10.00
> > rows=1000 width=12)
> >    ->  Sort  (cost=59.83..62.33 rows=1000 width=12)
> >          Sort Key: b.o
> >          ->  Function Scan on generate_series b  (cost=0.00..10.00
> > rows=1000 width=12)
> > (8 rows)

> > I think all that's required to avoid the sorts is teaching the planner
> > that the Path has a PathKey of the ordinal column. I can look at that
> > later but I'll go ahead and commit it without it at first. I wonder if
> > it's also useful to teach the planner that the column is unique.
> 
> So I took a crack at this. But it's not working.
> 
> To generate the pathkey for the ordinality column I basically exported
> make_pathkey_from_sortop() through a thin wrapper called
> make_pathkey_for_functionscan() and passed the Var from the reltargetlist and
> hard coded int8gt's oid. That might stand to be generalized a bit but in any
> case it doesn't matter because it doesn't work.

I think the patch is buggy in some ways.  I've reworked on the patch.  (I did
nothing on the uniqueness of an ordinality column.  We should do something on
that?)  Attached is a reworked version of the patch.  With the reworked version,
we get a plan for the above query:

postgres=# EXPLAIN SELECT * FROM generate_series(1,10) WITH ORDINALITY AS a(a,o)
NATURAL FULL OUTER JOIN generate_series(1,5) WITH ORDINALITY AS b(b,o);                                     QUERY PLAN
--------------------------------------------------------------------------------
-------Merge Full Join  (cost=0.01..97.50 rows=5000 width=24)  Merge Cond: (a.o = b.o)  ->  Function Scan on
generate_seriesa  (cost=0.00..10.00 rows=1000 width=12)  ->  Materialize  (cost=0.00..12.50 rows=1000 width=12)
-> Function Scan on generate_series b  (cost=0.00..10.00 rows=1000
 
width=12)
(5 rows)

> My best guess of what's going wrong is that the eclass is being generated too
> late and instead of getting the canonical eclass it's getting a freshly minted
> one that doesn't match the eclass for the merge join pathkey. But as I said,
> that's just a guess. I'm missing a high level view of the order of operations
> between turning parser column references into vars into eclasses and what has
> to be done when. My best guess is that what's needed is marking the ordinality
> column with a sortref early on but again, as I said, I'm just guessing.

You can find the discussion about this in src/backend/optimizer/README (Part:
Order of processing for EquivalenceClasses and PathKeys).

Thanks,

Best regards,
Etsuro Fujita