Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections

В Пт, 08/07/2022 в 11:04 -0400, Robert Haas пишет:
> On Fri, Jul 8, 2022 at 10:11 AM Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
> > I see analogy with Bus Stop:
> > - there is bus stop
> > - there is a schedule of bus arriving this top
> > - there are passengers, who every day travel with this bus
> >
> > Bus occasionally comes later... Well, it comes later quite often...
> >
> > Which way Major (or other responsible person) should act?
>
> I do not think that is a good analogy, because a bus schedule is an
> implicit promise - or at least a strong suggestion - that the bus will
> arrive at the scheduled time.

There is implicit promise: those data are written in single row.
If you want to notice they are NOT related to each other, return them
in different rows or even in different view tables.

> In this case, who made such a promise? The original post presents it
> as fact that these systems should give compatible answers at all
> times, but there's nothing in the code or documentation to suggest
> that this is true.
>
> IMHO, a better analogy would be if you noticed that the 7:03am bus was
> normally blue and you took that one because you have a small child who
> likes the color blue and it makes them happy to take a blue bus. And
> then one day the bus at that time is a red bus and your child is upset
> and you call the major (or other responsible person) to complain.
> They're probably not going to handle that situation by trying to send
> a blue bus at 7:03am as often as possible. They're going to tell you
> that they only promised you a bus at 7:03am, not what color it would
> be.
>
> Perhaps that's not an ideal analogy either, because the reported wait
> event and the reported activity are more closely related than the time
> of a bus is to the color of the bus. But I think it's still true that
> nobody ever promised that those values would be compatible with each
> other, and that's not really fixable, and that there are lots of other
> cases just like this one which can't be fixed either.
>
> I think that the more we try to pretend like it is possible to make
> these values seem like they are synchronized, the more unhappy people
> will be in the unavoidable cases where they aren't, and the more
> pressure there will be to try to tighten it up even further. That's
> likely to result in code that is more complex and slower, which I do
> not want, and especially not for the sake of avoiding a harmless
> reporting discrepancy.

Then just don't return them together, right?