Re: Custom explain options

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Custom explain options
Date: 2024-07-22 15:10:39
Message-ID: CAFj8pRANz+giP3Sr3q28QSPt1Vpte2Zrn4rv8Lsu8LRADK+W7w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

po 22. 7. 2024 v 17:08 odesílatel Konstantin Knizhnik <knizhnik(at)garret(dot)ru>
napsal:

>
> On 16/01/2024 5:38 pm, Tomas Vondra wrote:
>
> By "broken" you mean that you prefetch items only from a single leaf
>
> page, so immediately after reading the next one nothing is prefetched.
> Correct?
>
>
> Yes, exactly. It means that reading first heap page from next leaf page
> will be done without prefetch which in case of Neon means roundtrip with
> page server (~0.2msec within one data center).
>
>
> Yeah, I had this problem initially too, when I did the
> prefetching in the index AM code. One of the reasons why it got moved to
> the executor.
>
> Yeh, it works nice for vanilla Postgres. You call index_getnext_tid() and
> when it reaches end of leaf page it reads next read page. Because of OS
> read-ahead this read is expected to be fast even without prefetch. But not
> in Neon case - we have to download this page from page server (see above).
> So ideal solution for Neon will be to prefetch both leave pages and
> referenced heap pages. And prefetch of last one should be initiated as soon
> as leaf page is loaded. Unfortunately it is non-trivial to implement and
> current index scan prefetch implementation for Neon is not doing it.
>

What is the current state of this patch - it is abandoned? It needs a
rebase.

Regards

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-07-22 15:14:47 Re: [18] Policy on IMMUTABLE functions and Unicode updates
Previous Message Robert Haas 2024-07-22 15:02:51 Re: Assertion failure with summarize_wal enabled during pg_createsubscriber