Re: [Patch] Make ginInsertCleanup follow vacuum's BufferAccessStrategy
Re: [Patch] Make ginInsertCleanup follow vacuum's BufferAccessStrategy
От:
Xuneng Zhou <xunengzhou@gmail.com>
Дата:
Hi Kevin, On Wed, Aug 19, 2026 at 6:44 AM Kevin Rocker wrote: > > The vacuum callers of ginInsertCleanup weren't able to pass the current BufferAccessStrategy, since the function didn't take a strategy argument. I modified the function to take a strategy, and passed it from the vacuum down to ReadBufferExtended. Other call-sites pass NULL as a strategy, which preserves the current behavior. The rationale of this patch LGTM. > I did notice 6c228755add, which uses ReadStream in ginvacuumcleanup()'s full-index scan, but I don't think that will work here: that scan knows the full block range, but the pending-list needs to read each page to get the next block. I agree with this. That's why I did not add ginInsertCleanup as a candidate for read stream. > Running a quick test (script attached), we do see the strategy changing how GIN treats the buffer cache. I originally noticed this as just an inconsistency, but it may be a good improvement to how GIN vacuum interacts with shared buffers (fewer evictions on other processes). > > - Kevin Rocker -- Regards, Xuneng Zhou HighGo Software Co., Ltd.
Re: psql variable substitution in plpgsql loop
От:
"David G. Johnston" <david.g.johnston@gmail.com>
Дата:
On Sunday, June 21, 2026, carl clemens <cclemens968@gmail.com> wrote:
psql fails to populate a table in variable substitution.the variable being within a plpgsql "goto" loop looks suspicious
psql will not modify string literals when performing variable substitution.
David J.
Re: psql variable substitution in plpgsql loop
От:
carl clemens <cclemens968@gmail.com>
Дата:
ok, no problem.
Thanks
On Sun, Jun 21, 2026 at 6:17 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Sunday, June 21, 2026, carl clemens <cclemens968@gmail.com> wrote:psql fails to populate a table in variable substitution.the variable being within a plpgsql "goto" loop looks suspiciouspsql will not modify string literals when performing variable substitution.David J.