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
-
Add TID Range Scans to support efficient scanning ranges of TIDs
- bb437f995d47 14.0 landed
-
Improve planner's selectivity estimates for inequalities on CTID.
- f7111f72d2fd 12.0 landed