Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 08:33:55PM +0300, Vladimir Borodin wrote: > That’s why proposal included GUC for that with a default to turn timings > measuring off. I don’t remember any objections against that. > > And I’m absolutely sure that a real highload production (which of course > doesn’t use

Re: [HACKERS] Background Processes and reporting

> 15 марта 2016 г., в 19:57, Oleg Bartunov написал(а): > > > > On Tue, Mar 15, 2016 at 7:43 PM, Alexander Korotkov > > wrote: > On Tue, Mar 15, 2016 at 12:57 AM, Robert Haas

Re: [HACKERS] Background Processes and reporting

On Tue, Mar 15, 2016 at 7:43 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Tue, Mar 15, 2016 at 12:57 AM, Robert Haas > wrote: > >> On Mon, Mar 14, 2016 at 4:42 PM, Andres Freund >> wrote: >> > On 2016-03-14 16:16:43 -0400, Robert

Re: [HACKERS] Background Processes and reporting

On Tue, Mar 15, 2016 at 12:57 AM, Robert Haas wrote: > On Mon, Mar 14, 2016 at 4:42 PM, Andres Freund wrote: > > On 2016-03-14 16:16:43 -0400, Robert Haas wrote: > >> > I have already shown [0, 1] the overhead of measuring timings in > linux on > >> >

Re: [HACKERS] Background Processes and reporting

On Tue, Mar 15, 2016 at 1:32 AM, Andres Freund wrote: > > On 2016-03-12 16:29:11 +0530, Amit Kapila wrote: > > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund wrote: > > > > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > >

Re: [HACKERS] Background Processes and reporting

On Mon, Mar 14, 2016 at 4:42 PM, Andres Freund wrote: > On 2016-03-14 16:16:43 -0400, Robert Haas wrote: >> > I have already shown [0, 1] the overhead of measuring timings in linux on >> > representative workload. AFAIK, these tests were the only one that showed >> > any

Re: [HACKERS] Background Processes and reporting

Hi, On 2016-03-14 16:16:43 -0400, Robert Haas wrote: > > I have already shown [0, 1] the overhead of measuring timings in linux on > > representative workload. AFAIK, these tests were the only one that showed > > any numbers. All other statements about terrible performance have been and > >

Re: [HACKERS] Background Processes and reporting

On Mon, Mar 14, 2016 at 3:54 PM, Vladimir Borodin wrote: > 5. Show extra information about wait event (i.e. exclusive of shared mode > for LWLocks, relation/forknum/blknum for I/O operations, etc.). I doubt that this is a good idea. Everybody will pay the cost of it, and who

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 16:29:11 +0530, Amit Kapila wrote: > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in many cases processes that very often are > > > blocked on locks,

Re: [HACKERS] Background Processes and reporting

> 14 марта 2016 г., в 22:21, Robert Haas написал(а): > > On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >>> So? >> >> So, Robert already has experience with the subject, probably, he has bad >> experience with edb implementation and he'd

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 6:05 AM, Oleg Bartunov wrote: >> So? > > So, Robert already has experience with the subject, probably, he has bad > experience with edb implementation and he'd like to see something better in > community version. That's fair and I accept his position.

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 11:40 AM, Vladimir Borodin wrote: > 12 марта 2016 г., в 13:59, Amit Kapila написал(а): >> I think here another point which needs more thoughts is that many of the >> pg_stat_activity fields are not relevant for background

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 13:59, Amit Kapila написал(а): > > On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund > wrote: > > > > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > > background writer are in

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 2:45, Andres Freund написал(а): > > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: >> Idea of individual time measurement of every wait event met criticism >> because it might have high overhead [1]. > > Right. And that's actually one of the

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 2:38 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > > On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund wrote: >> >> >> I think I agree with Robert here. Providing hooks into very low level >> places tends to lead to problems in my

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 12:45 AM, Andres Freund wrote: > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > > > > So, situation looks like dead-end. I have no idea how to convince Robert > > about any kind of advanced functionality of wait monitoring to > PostgreSQL.

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 3:10 AM, Andres Freund wrote: > > > > Similarly for the wait event stuff - checkpointer, wal writer, > > background writer are in many cases processes that very often are > > blocked on locks, IO and such. Thus restricting the facility to > > database

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund wrote: > On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > > Idea of individual time measurement of every wait event met criticism > > because it might have high overhead [1]. > > Right. And that's actually one of the

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 02:24:33 +0300, Alexander Korotkov wrote: > Idea of individual time measurement of every wait event met criticism > because it might have high overhead [1]. Right. And that's actually one of the point which I meant with "didn't listen to criticism". There've been a lot of examples,

Re: [HACKERS] Background Processes and reporting

On Sat, Mar 12, 2016 at 12:22 AM, Andres Freund wrote: > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: > > It was many times stated in threads about waits monitoring [0, 1, 2] > > and supported by different people, but ultimately waits information > > was stored in

Re: [HACKERS] Background Processes and reporting

On 2016-03-12 01:05:43 +0300, Vladimir Borodin wrote: > > 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > Only that it isn't. It's stored in PGPROC. > > Sorry, I missed that. So monitoring of wait events for auxiliary processes > still could be implemented? It's

Re: [HACKERS] Background Processes and reporting

> 12 марта 2016 г., в 0:22, Andres Freund написал(а): > > On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: >> It was many times stated in threads about waits monitoring [0, 1, 2] >> and supported by different people, but ultimately waits information >> was stored in

Re: [HACKERS] Background Processes and reporting

Hi, On 2016-03-11 11:16:32 -0800, Andres Freund wrote: > It seems rather worthwhile to think about how we can expand the coverage > of progress tracking to other types of background processes. WRT the progress reporting patch, I think we should split (as afaics was discussed in the thread for a

Re: [HACKERS] Background Processes and reporting

On 2016-03-11 23:53:15 +0300, Vladimir Borodin wrote: > It was many times stated in threads about waits monitoring [0, 1, 2] > and supported by different people, but ultimately waits information > was stored in PgBackendStatus. Only that it isn't. It's stored in PGPROC. This criticism is true of

Re: [HACKERS] Background Processes and reporting

> 11 марта 2016 г., в 22:16, Andres Freund написал(а): > > Hi, > > We now have "Provide much better wait information in pg_stat_activity" > and "Add a generic command progress reporting facility" making it easier > to provide insight into the system. > > > While working

[HACKERS] Background Processes and reporting

Hi, We now have "Provide much better wait information in pg_stat_activity" and "Add a generic command progress reporting facility" making it easier to provide insight into the system. While working on the writeback control / checkpoint sorting patch I'd the following statement in BufferSync()'s