From: | Junwang Zhao <zhjwpku(at)gmail(dot)com> |
---|---|
To: | Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> |
Cc: | Amit Langote <amitlangote09(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some ExecSeqScan optimizations |
Date: | 2025-01-11 09:00:06 |
Message-ID: | CAEG8a3+xQDDAe_ZkN3DFqApKrYmbp-FNweZ5b4DJBhKJbzAHCA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 11, 2025 at 4:57 PM Junwang Zhao <zhjwpku(at)gmail(dot)com> wrote:
>
> On Fri, Jan 10, 2025 at 10:49 PM Vladlen Popolitov
> <v(dot)popolitov(at)postgrespro(dot)ru> wrote:
> >
> > Amit Langote писал(а) 2025-01-10 18:22:
> > > On Fri, Jan 10, 2025 at 7:36 PM David Rowley <dgrowleyml(at)gmail(dot)com>
> > > wrote:
> > >> On Fri, 10 Jan 2025 at 22:53, Vladlen Popolitov
> > >> <v(dot)popolitov(at)postgrespro(dot)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.
> > >
> > > Vladlen, does what David wrote and the new commit message answer your
> > > question(s)?
> >
> > Hi Amit,
> >
> > Yes, David clarified the idea, but it is still hard to believe in 5% of
> > improvements.
> > The query
> > select count(*) from test_table where a_1 = 1000000;
> > has both qual and projection, and ExecScanExtended() will be generated
> > similar to ExecScan() (the same not NULL values to check in if()).
> > Do you have some scripts to reproduce your benchmark?
>
> The benchmark is provided [0].
>
> Here is a rough comparison of compiled variants' assembly code.
>
> <ExecSeqScan>: start 2b8590, end 2b868c => 252
> <ExecSeqScanWithProject>: start 2b8034, end 2b8140 => 268
> <ExecSeqScanWithQual>: start 2b8144, end 2b831c => 472
> <ExecSeqScanWithQualProject>: start 2b8320, end 2b858c => 620
Here is my compile options:
meson setup $HOME/build --prefix=$HOME/pgsql --buildtype=release
and I use `objdump -D postgres | less` to see the assembly code.
>
> Before Amit's optimization, it was basically called the
> ExecSeqScanWithQualProject, you
> can see the other 3 variants all have some reduction in function size.
>
> > --
> > Best regards,
> >
> > Vladlen Popolitov.
>
> [0] https://docs.google.com/spreadsheets/d/1AsJOUgIfSsYIJUJwbXk4aO9FVOFOrBCvrfmdQYkHIw4/edit?usp=sharing
>
> --
> Regards
> Junwang Zhao
--
Regards
Junwang Zhao
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2025-01-11 09:02:50 | Re: pgsql: Consolidate docs for vacuum-related GUCs in new subsection |
Previous Message | Junwang Zhao | 2025-01-11 08:57:12 | Re: Some ExecSeqScan optimizations |