Re: Some ExecSeqScan optimizations
От | Junwang Zhao |
---|---|
Тема | Re: Some ExecSeqScan optimizations |
Дата | |
Msg-id | CAEG8a3K=Yq8U8-XL0oe=UCCDUKV1a+nYNktcssp7Ly9w3+MabA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Some ExecSeqScan optimizations (Vladlen Popolitov <v.popolitov@postgrespro.ru>) |
Ответы |
Re: Some ExecSeqScan optimizations
|
Список | pgsql-hackers |
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. There is one tiny indent issue(my IDE does this automatically), which I guess you will fix before committing. - EPQState *epqstate; + EPQState *epqstate; > > Vladlen, does what David wrote and the new commit message answer your > question(s)? > > -- > Thanks, Amit Langote -- Regards Junwang Zhao
В списке pgsql-hackers по дате отправления: