Date: Wed, 27 Mar 2019 13:36:08 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Message-ID: <1553718968249-0.post@n3.nabble.com>
In-Reply-To: 
 <CAOBaU_aX2Ad_pcSWGUQ1YFk8gotwoMYJDg5Wmosh7jj+28AQ4w@mail.gmail.com>
References: 
 <DB6PR0301MB21352F6210E3B11934B0DCC790B00@DB6PR0301MB2135.eurprd03.prod.outlook.com>
 <6112091549979517@myt5-a323eb993ef7.qloud-c.yandex.net>
 <1550179299067-0.post@n3.nabble.com>
 <2205341550215950@sas1-cd55e40a6ba0.qloud-c.yandex.net>
 <DB6PR0301MB2135B4B1D256F547966A559B90430@DB6PR0301MB2135.eurprd03.prod.outlook.com>
 <CAOBaU_Yq6motvaqXE_vBWf=SsRANij=+jE3Xa4qCmzGb24LkzA@mail.gmail.com>
 <DB6PR0301MB21351B7CDA68EFE4838562EC905C0@DB6PR0301MB2135.eurprd03.prod.outlook.com>
 <CAOBaU_bU1m3_XF5qKYtSj1ua4dxd=FWDyh2SH4rSJAUUfsGmAQ@mail.gmail.com>
 <DB6PR0301MB2135B8CE071A02D2D663CFA1905F0@DB6PR0301MB2135.eurprd03.prod.outlook.com>
 <CAOBaU_aX2Ad_pcSWGUQ1YFk8gotwoMYJDg5Wmosh7jj+28AQ4w@mail.gmail.com>
Subject: Re: Planning counters in pg_stat_statements (using pgss_store)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

>>     - trailing whitespaces and comments wider than 80 characters
>>          not fixed

> why?  In case it's not clear, I'm talking about the .c file, not the
> regression tests.

I work on a poor msys install on windows 7, where perl is broken ;o(
So no pgindent available. 
Will fix that later, or as soon as I get a pgindent diff.

>>     - "Assert(planning_time > 0 && total_time > 0);"
>>          moved at the beginning of pgss_store

> Have you tried to actually compile postgres and pg_stat_statements
> with --enable-cassert?  This test can *never* be true, since you
> either provide the planning time or the execution time or neither.  As
> I said in my previous mail, adding a parameter to say which counter
> you're updating, instead of adding another counter that's mutually
> exclusive with the other would make everything clearer.

Yes this "assert" is useless as is ... I'll remove it.
I understand you proposal of pgss_store refactoring, but I don't have 
much time available now ... and I would like to check that performances 
are not broken before any other modification ...

Regards
PAscal


--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html