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 08:57:12 |
Message-ID: | CAEG8a3K=OMubWZdzLdR=Skrs0wvSZijyWmyEFvBiwnx3kH4GEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
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
From | Date | Subject | |
---|---|---|---|
Next Message | Junwang Zhao | 2025-01-11 09:00:06 | Re: Some ExecSeqScan optimizations |
Previous Message | Alvaro Herrera | 2025-01-11 08:44:39 | Re: Non-text mode for pg_dumpall |