Hi Junwang, On Sat, Jan 11, 2025 at 7:39 PM Junwang Zhao <zhjw...@gmail.com> wrote: > Hi Amit, > > On Fri, Jan 10, 2025 at 7:22 PM Amit Langote <amitlangot...@gmail.com> wrote: > > > > On Fri, Jan 10, 2025 at 7:36 PM David Rowley <dgrowle...@gmail.com> wrote: > > > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov > > > <v.popoli...@postgrespro.ru> wrote: > > > > In case of query > > > > select count(*) from test_table where a_1 = 1000000; > > > > I would expect increase of query time due to additional if...else . It > > > > is not clear > > > > what code was eliminated to decrease query time. > > > > > > Are you talking about the code added to ExecInitSeqScan() to determine > > > which node function to call? If so, that's only called during executor > > > startup. The idea here is to reduce the branching during execution by > > > calling one of those special functions which has a more specialised > > > version of the ExecScan code for the particular purpose it's going to > > > be used for. > > > > Looks like I hadn't mentioned this key aspect of the patch in the > > commit message, so did that in the attached. > > Thanks for updating the patch. While seeing the patch, the es_epq_active > confused me a little bit mostly because its name, a field name ending with > "active" typically suggests a boolean value, but here it is not, should we > change it to sth like es_epqstate? However this is not related to this patch, > I can start a new thread if you think this is worth a patch.
Yeah, the name has confused me as well from time to time. Though it might be a good idea to dig the thread that led to the introduction of this field to find out if the naming has some logic we're missing. You may start a new thread to get the attention of other folks who might have some clue. > There is one tiny indent issue(my IDE does this automatically), which I > guess you will fix before committing. > > - EPQState *epqstate; > + EPQState *epqstate; Thanks for the heads up. -- Thanks, Amit Langote
