Re: Perf: Specialize ExecIndexOnlyScan() like ExecSeqScan()

Hi Matthias!

> this is my first patch for Postgres, so please let me know if I got
> something about the contribution policies wrong.

Welcome and thanks for your contribution!

> Our main workload does a lot of index-only scans, and in perf profiles
> of it
> a good part of the time showed up under ExecScan(). Digging into the
> code I noticed that IndexScan, IndexOnlyScan and BitmapHeapScan all
> still go through the generic out-of-line ExecScan(). So each tuple pays
> for an indirect call to the access method and for the runtime EPQ /
> qual / projection checks. SeqScan got rid of that with fb9f95502 (and
> 83a53572a6f made sure SeqNext actually gets inlined).
>
> The attached patch does the same for index-only scans. There are now
> ExecIndexOnlyScan, ...WithQuals, ...WithProject, ...WithQualProject and
> ...EPQ, the variant is picked in ExecInitIndexOnlyScan(), and
> IndexOnlyNext() is pg_always_inline. The EPQ variant just calls
> ExecScan() like ExecSeqScanEPQ does.
+1 on doing that change for Index (Only) Scan.

It would propose to do it as well for Bitmap Index Scan. Then we cover
the three most important table access plan nodes.

Beyond that, ExecScan() is used by many more nodes (Tid Scan, CTE Scan,
etc.). I'm wondering how similar the code would be to make all - or at
least most - of them work and if we cannot write some shared abstraction
that saves us from repeating all the boiler plate.

--
David Geier