On Thu, Oct 17, 2024 at 5:03 AM Matthias van de Meent
wrote:
>
> On Thu, 17 Oct 2024 at 00:33, Peter Geoghegan wrote:
> >
> > On Wed, Oct 16, 2024 at 5:48 PM Matthias van de Meent
> > wrote:
> > > In v17 and the master branch you'll note 16 buffer hits for the test
> > > query. However, when we
On Fri, 11 Oct 2024 at 16:27, Matthias van de Meent wrote:
>
> Hi,
>
> With PG17's new SAOP handling the performance of certain index scans
> significantly improved performance in the serial case. However, for
> parallel index scans the performance picture is not as
> straightforward, and this has
On Thu, 17 Oct 2024 at 00:33, Peter Geoghegan wrote:
>
> On Wed, Oct 16, 2024 at 5:48 PM Matthias van de Meent
> wrote:
> > In v17 and the master branch you'll note 16 buffer hits for the test
> > query. However, when we use more expensive btree compare operations
> > (e.g. by adding pg_usleep(1)
On Wed, Oct 16, 2024 at 5:48 PM Matthias van de Meent
wrote:
> In v17 and the master branch you'll note 16 buffer hits for the test
> query. However, when we use more expensive btree compare operations
> (e.g. by adding pg_usleep(1) to both btint8cmp and btint4cmp), the
> buffer access count start
On Wed, 16 Oct 2024 at 20:52, Peter Geoghegan wrote:
>
> On Fri, Oct 11, 2024 at 10:27 AM Matthias van de Meent
> wrote:
> > With the introduction of the new SAOP handling in PG17, however, the
> > shared state has become a bit more muddied. Because the default has
> > changed from "stop scanning
On Fri, Oct 11, 2024 at 10:27 AM Matthias van de Meent
wrote:
> With the introduction of the new SAOP handling in PG17, however, the
> shared state has become a bit more muddied. Because the default has
> changed from "stop scanning at the end of a SAOP value's range" to
> "continue scanning, unle
