Re: Tid scan improvements

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Edmund Horner <ejrh00@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2018-12-21T16:57:48Z
Lists: pgsql-hackers
Edmund Horner <ejrh00@gmail.com> writes:
> 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.

Check.

> For the (optional) backwards scan support patch, should we separately
> emit another path, in the reverse direction?

What indxpath.c does is, if has_useful_pathkeys is true, to generate
pathkeys both ways and then build paths if the pathkeys get past
truncate_useless_pathkeys.  That seems sufficient in this case too.
There are various heuristics about whether it's really useful to
consider both sort directions, but that intelligence is already
built into truncate_useless_pathkeys.  tid quals with no pathkeys
would be reason to generate a forward path, but not reason to
generate a reverse path, because then that would be duplicative.

			regards, tom lane


Commits

  1. Add TID Range Scans to support efficient scanning ranges of TIDs

  2. Improve planner's selectivity estimates for inequalities on CTID.