On 1/17/24 09:45, Konstantin Knizhnik wrote: > I have integrated your prefetch patch in Neon and it actually works! > Moreover, I combined it with prefetch of leaf pages for IOS and it also > seems to work. >
Cool! And do you think this is the right design/way to do this? > Just small notice: you are reporting `blks_prefetch_rounds` in explain, > but it is not incremented anywhere. > Moreover, I do not precisely understand what it mean and wonder if such > information is useful for analyzing query executing plan. > Also your patch always report number of prefetched blocks (and rounds) > if them are not zero. > Right, this needs fixing. > I think that adding new information to explain it may cause some > problems because there are a lot of different tools which parse explain > report to visualize it, > make some recommendations top improve performance, ... Certainly good > practice for such tools is to ignore all unknown tags. But I am not sure > that everybody follow this practice. > It seems to be more safe and at the same time convenient for users to > add extra tag to explain to enable/disable prefetch info (as it was done > in Neon). > I think we want to add this info to explain, but maybe it should be behind a new flag and disabled by default. > Here we come back to my custom explain patch;) Actually using it is not > necessary. You can manually add "prefetch" option to Postgres core (as > it is currently done in Neon). > Yeah, I think that's the right solution. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
