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
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 |