On Wed, Jul 4, 2018 at 11:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes: > At Mon, 2 Jul 2018 14:25:58 -0400, Robert Haas <robertmhaas@gmail.com> wrote in <CA+TgmoYQhr30eAcgJCi1v0FhA+3RP1FZVnXqSTLe=6fHy9e5oA@mail.gmail.com> >> Copying the whole hash table kinds of sucks, partly because of the >> time it will take to copy it, but also because it means that memory >> usage is still O(nbackends * ntables). Without looking at the patch, >> I'm guessing that you're doing that because we need a way to show each >> transaction a consistent snapshot of the data, and I admit that I >> don't see another obvious way to tackle that problem. Still, it would >> be nice if we had a better idea.
> The consistency here means "repeatable read" of an object's stats > entry, not a snapshot covering all objects. We don't need to copy > all the entries at once following this definition. The attached > version makes a cache entry only for requested objects.
Uh, what? That's basically destroying the long-standing semantics of statistics snapshots. I do not think we can consider that acceptable. As an example, it would mean that scan counts for indexes would not match up with scan counts for their tables.
I agree that this is definitely something that needs to be considered. I took a look some time ago at the same thing, and ran up against exactly that one (and at the time did not have time to fix it).
I have not yet had time to look at the downstream suggested handling (UNDO). However, I had one other thing from my notes I wanted to mention :)
We should probably consider adding an API to fetch counters that *don't* follow these rules, in case it's not needed. When going through files we're still stuck at that bottleneck, but if going through shared memory it should be possible to make it a lot cheaper by volunteering to "not need that".
We should also consider the ability to fetch stats for a single object, which would require no copying of the whole structure at all. I think something like this could for example be used for autovacuum rechecks. On top of the file based transfer that would help very little, but through shared memory it could be a lot lighter weight.