|From:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|To:||Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>|
|Subject:||Re: idea: log_statement_sample_rate - bottom limit for sampling|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Aug 02, 2019 at 09:53:40AM +0200, Adrien Nayrat wrote:
>On 8/1/19 12:04 PM, Tomas Vondra wrote:
>> On Thu, Aug 01, 2019 at 11:47:46AM +0200, Adrien Nayrat wrote:
>>> As we are at the end of this CF and there is still discussions about whether we
>>> should revert log_statement_sample_limit and log_statement_sample_rate, or try
>>> to fix it in v12.
>>> I moved this patch to next commit fest and change status from "ready for
>>> commiter" to "need review". I hope I didn't make a mistake.
>> Thanks. The RFC status was clearly stale, so thanks for updating. I should
>> have done that after my review. I think the patch would be moved to the
>> next CF at the end, but I might be wrong. In any case, I don't think
>> you've done any mistake.
>> As for the sampling patch - I think we'll end up reverting the feature for
>> v12 - it's far too late to rework it at this point. Sorry about that, I
>> know it's not a warm feeling when you get something done, and then it gets
>> reverted on the last minute. :-(
>Don't worry, I understand. It is better to add straigforward GUC in v13 than
>confusionning in v12 we will regret.
OK, I have the revert ready. The one thing I'm wondering about is
whether we need to revert log_transaction_sample_rate too? I think it's
pretty much independent feature, so I think we can keep that. Opinions?
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||Tom Lane||2019-08-04 19:14:07||Re: Patch to clean Query after rewrite-and-analyze - reduces memusage up to 50% - increases TPS by up to 50%|
|Previous Message||Alvaro Herrera||2019-08-04 19:00:53||Re: pgsql: Improve pruning of a default partition|