Hi,
On Wed, 2021-03-31 at 22:10 +0200, Mats Kindahl wrote:
> As an example of how this is useful, I noticed the work by Heikki and
> Ashwin [1], where they return a `TableScanDesc` that contains
> information about what columns to scan, which looks very useful.
> Since
> the function `table_beginscan` in `src/include/access/tableam.h`
> accept a `ScanKey` as input, this is (AFAICT) what Heikki and Ashwin
> was exploiting to create a specialized scan for a columnar store.
I don't think ScanKeys are the right place to store information about
what columns would be useful. See another thread[2] about that topic.
> Another example of where this can be useful is to optimize access
> during a sequential scan when you can handle some specific scans very
> efficiently and can "skip ahead" many tuples if you know what is
> being
> looked for instead of filtering "late". Two examples of where this
> could be useful are:
>
> - An access method that reads data from a remote system and doesn't
> want
> to transfer all tuples unless necessary.
> - Some sort of log-structured storage with Bloom filters that allows
> you to quickly skip suites that do not have a key.
I agree that would be very conventient for non-heap AMs. There's a very
old commit[3] that says:
+ /*
+ * Note that unlike IndexScan, SeqScan never use keys
+ * in heap_beginscan (and this is very bad) - so, here
+ * we have not check are keys ok or not.
+ */
and that language has just been carried forward for decades. I wonder
if there's any major reason this hasn't been done yet. Does it just not
improve performance for a heap, or is there some other reason?
Regards,
Jeff Davis
[2]
https://www.postgresql.org/message-id/CAE-ML+9RmTNzKCNTZPQf8O3b-UjHWGFbSoXpQa3Wvuc8YBbEQw@mail.gmail.com
[3]
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e3a1ab764ef2