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
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 caused some issues earlier.
Background
--
Before PG17, we had o
