>I have let this stuff cool down for a couple of days, still it seems to me
>that having one single column makes the most sense when it comes when
>looking at a mostly idle system. I'll try to finish this one at the
>beginning of next week, for now I am marking as ready for committer.
Thank you f
>> I have been looking at this patch more in-depth, and you missed one
>> critical thing: hot standby feedback messages also include the
>> timestamp the client used when sending the message, so if we want to
>> track the latest time when a message has been sent we should track it
>> as much as the
>On Mon, Nov 26, 2018 at 02:48:39PM +0900, myungkyu.lim wrote:
>> So I selected 'reply_time' because 'timestamp' was not used in stat
>> field.
>
>Fine by me. Could you send a new patch please? I am switching the patch
as
>waiting on author for now.
On Thu, Nov 15, 2018 at 5:27 PM Michael Paquier wrote:
>> Good point. 'last_reply_send_time' is better.
>> How about just 'reply_time'?
>
>Please note that the original thread has mentioned reply_timestamp as a
>consensus:
So I selected 'reply_time' because 'timestamp' was not used in stat field.
Hi.
>> I changed field name from 'reply_time' to 'last_msg_send_time'.
>> Because 'last_msg_send_time' is used in
>> pg_stat_wal_receiver/pg_stat_subsctiption view.
>> I think that field has the same meaning.
>
>I got confused by the field name. If we have 'last_msg_send_time'
>field in pg_stat_r
Hi.
Thanks for your feedback.
> Can you explain the purpose of this feature more because now we have columns
> to report replication delay times like write_lag ,flush_lag and replay_lag
> that can use for similar purpose .
I think, time elapsed stats are very useful on DML query active system,
>> COPY table_name WHERE (some_condition)
>>
>> Users should already be familiar with the idea that WHERE performs a filter.
>>
> So, what about using FILTER here? We already use it for aggregates when
> filtering rows to process.
> That being said, I have no strong feelings either way. I'd be
Hello,
Basically, this patch worked very well in my tests.
> 3) For COPY TO, the WHEN clause is accepted but ignored, leading to confusing
> cases like this:
I found same issue.
postgres=# copy t1 to '/home/lmk/t1.data' when c1 < 1;
In the 'COPY TO' statement, 'WHEN clause' does not do an
