On 2019-Aug-09, Tom Lane wrote:
> I poked at this, and attached is a patch, but again I'm not seeing
> that there's any real performance-based argument for it. So far
> as I can tell, if we've got a lot of RTEs in an executable plan,
> the bulk of the startup time is going into lock (re) acquisition in
> AcquirePlannerLocks, and/or permissions scanning in ExecCheckRTPerms;
> both of those have to do work for every RTE including ones that
> run-time pruning drops later on. ExecInitRangeTable just isn't on
> the radar.
I'm confused. I thought that the point of doing this wasn't that we
wanted to improve performance, but rather that we're now able to remove
the array without *losing* performance. I mean, those arrays were there
to improve performance for code that wanted fast access to specific list
items, but now we have fast access to the list items without it. So a
measurement that finds no performance difference is good news, and we
can get rid of the now-pointless optimization ...
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
