On Fri, Jan 10, 2025 at 1:06 PM David Rowley <dgrowle...@gmail.com> wrote: > On Fri, 10 Jan 2025 at 02:46, Amit Langote <amitlangot...@gmail.com> wrote: > > > > On Mon, Jan 6, 2025 at 10:18 PM David Rowley <dgrowle...@gmail.com> wrote: > > > I've attached my workings of what I was messing around with. It seems > > > to perform about the same as your version. I think maybe we'd need > > > some sort of execScan.h instead of where I've stuffed the functions > > > in. > > > > I've done that in the attached v2. > > I think 0001 looks ok, aside from what the attached fixes. (at least > one is my mistake)
Oops, thanks for the fixes. Attaching an updated version.
> Did you test the performance of 0002? I didn't look at it hard enough
> to understand what you've done.
I reran the test suite I used before and I don't see a consistent
improvement due to 0002 or perhaps rather degradation. I've saved the
results in the sheet named 2025-01-10 in the spreadsheet at [1].
Comparing the latency for the query `select count(*) from test_table
where <first_column> = <nonexistant_value>` (where test_table has 30
integer columns and 1 million rows in it) between v17, master, and the
patched (0001 or 0001+0002) shows an improvement of close to 10% with
the patch.
-- v17
select count(*) from test_table where a_1 = 1000000;
count
-------
0
(1 row)
Time: 286.618 ms
-- master
select count(*) from test_table where a_1 = 1000000;
count
-------
0
(1 row)
Time: 283.564 ms
-- patched (0001+0002)
select count(*) from test_table where a_1 = 1000000;
count
-------
0
(1 row)
Time: 260.547 ms
Note that I turned off Gather for these tests, because then I find
that the improvements to ExecScan() are better measurable.
> I can look if performance tests show
> that it might be worthwhile considering.
Sure, that would be great.
--
Thanks, Amit Langote
v3-0002-Break-ExecScanExtended-into-variants-based-on-qua.patch
Description: Binary data
v3-0001-Refactor-ExecScan-to-inline-scan-filtering-and-pr.patch
Description: Binary data
