Re: index prefetching
| От | Peter Geoghegan |
|---|---|
| Тема | Re: index prefetching |
| Дата | |
| Msg-id | CAH2-Wzm6yf7rLAzmpnEnvc_0E5y-2p_pTQ++TNxdQgo=VnZLQQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: index prefetching (Andres Freund <andres@anarazel.de>) |
| Список | pgsql-hackers |
On Mon, Nov 24, 2025 at 3:48 PM Andres Freund <andres@anarazel.de> wrote: > Huh. I wouldn't have expected -march=native to make a huge difference... Me neither. On the other hand I find that this area is quite sensitive to icache misses and branch misprediction penalties. This is partly due to my holding the patch to a very high standard, in terms of avoiding regressions (at least for simple point lookup queries and nestloop join queries). > I don't think the precise gains here, particularly basedon on quick > prototypes, make that much of a difference. There's so much more optimization > potential other than the amortization of locking costs... I agree that this precise issue isn't necessarily all that important. My current focus is on completely separating the I/O prefetching parts of the patch from the core AM interface changes, while avoiding regressions shown by various microbenchmarks. My experiments with -march=native were mostly about that -- not about the heap buffer locking thing specifically. That was just something I noticed in passing, and found curious. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: