On Fri, 21 Dec 2018 at 16:31, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Edmund Horner <ejrh00@gmail.com> writes:
> > For the forward scan, I seem to recall, from your merge join example,
> > that it's useful to set the pathkeys even when there are no
> > query_pathkeys. We just have to unconditionally set them so that the
> > larger plan can make use of them.
>
> No. Look at indxpath.c: it does not worry about pathkeys unless
> has_useful_pathkeys is true, and it definitely does not generate
> pathkeys that don't get past truncate_useless_pathkeys. Those
> functions are responsible for worrying about whether mergejoin
> can use the pathkeys. It's not tidpath.c's job to outthink them.
Ok. I think that will simplify things. So if I follow you correctly,
we should do:
1. If has_useful_pathkeys is true: generate pathkeys (for CTID ASC),
and use truncate_useless_pathkeys on them.
2. If we have tid quals or pathkeys, emit a TID scan path.
For the (optional) backwards scan support patch, should we separately
emit another path, in the reverse direction? (My current patch only
creates one path, and tries to decide what the best direction is by
looking at query_pathkeys. This doesn't fit into the above
algorithm.)