Re: Some ExecSeqScan optimizations

On Fri, Jan 10, 2025 at 1:06 PM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> On Fri, 10 Jan 2025 at 02:46, Amit Langote <amitlangote09(at)gmail(dot)com> wrote:
> >
> > On Mon, Jan 6, 2025 at 10:18 PM David Rowley <dgrowleyml(at)gmail(dot)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