Hi Junwang,
On Sat, Jan 11, 2025 at 7:39 PM Junwang Zhao <zhjwpku@gmail.com> wrote:
> Hi Amit,
>
> On Fri, Jan 10, 2025 at 7:22 PM Amit Langote <amitlangote09@gmail.com> wrote:
> >
> > On Fri, Jan 10, 2025 at 7:36 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > > On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > > <v.popolitov@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
