Re: [PATCH] fix wait_event of pg_stat_activity in case of high amount of connections - Mailing list pgsql-hackers

В Сб, 09/07/2022 в 02:32 +0300, Yura Sokolov пишет:
> В Пт, 08/07/2022 в 11:04 -0400, Robert Haas пишет:
> > On Fri, Jul 8, 2022 at 10:11 AM Yura Sokolov <y.sokolov@postgrespro.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?

Well, I'm a bit hotter guy than it is needed. I appologize for that.

Lets look on situation from compromise point of view:
- We are telling: we could make this view more synchronous (and faster).
- You are telling: it will never be totally synchronous, and it is
  mistake we didn't mention the issue in documentation.

Why don't do both?
Why can't we do it more synchronous (and faster) AND mention in
documentaion it is not totally synchronous and never will be?

--------

regards

Yura