In preparing to push the patch, I noticed I hadn't responded to this:
Gurjeet Singh gurj...@singh.im wrote:
Kevin Grittner kgri...@ymail.com wrote:
I have reviewed this patch, and think we should do what the patch
is trying to do, but I don't think the submitted patch would
actually work.
Gurjeet Singh gurj...@singh.im wrote:
On Wed, Jul 2, 2014 at 3:49 PM, Kevin Grittner kgri...@ymail.com wrote:
Gurjeet Singh gurj...@singh.im wrote:
Kevin Grittner kgri...@ymail.com wrote:
I have reviewed this patch, and think we should do what the patch
is trying to do, but I don't think the
Tom Lane t...@sss.pgh.pa.us wrote:
If we're going to do it like this, then I think the force flag
should be considered to do nothing except override the clock
check, which probably means it shouldn't be tested in the initial
if() at all.
That makes sense, and is easily done. The only
I have reviewed this patch, and think we should do what the patch
is trying to do, but I don't think the submitted patch would
actually work. I have attached a suggested patch which I think
would work. Gurjeet, could you take a look at it?
My comments on prior discussion embedded below.
Kevin Grittner kgri...@ymail.com writes:
Gurjeet Singh gurj...@singh.im wrote:
Besides, there's already a throttle built in using the
PGSTAT_STAT_INTERVAL limit.
This is a key point; neither the original patch nor my proposed
alternative bypasses that throttling.
That's a fair point that
Please find attached the patch to send transaction commit/rollback stats to
stats collector unconditionally.
Without this patch, the transactions that do not read from/write to a
database table do not get reported to the stats collector until the client
disconnects. Hence the transaction counts
Gurjeet Singh gurj...@singh.im writes:
Please find attached the patch to send transaction commit/rollback stats to
stats collector unconditionally.
That's intentional to reduce stats traffic. What kind of performance
penalty does this patch impose? If the number of such transactions is
large
On Wed, Mar 19, 2014 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
Please find attached the patch to send transaction commit/rollback stats
to
stats collector unconditionally.
That's intentional to reduce stats traffic. What kind of performance
Gurjeet Singh wrote:
On Wed, Mar 19, 2014 at 4:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Gurjeet Singh gurj...@singh.im writes:
Please find attached the patch to send transaction commit/rollback stats
to
stats collector unconditionally.
That's intentional to reduce stats traffic.
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm not sure I understand the point of this whole thing. Realistically,
how many transactions are there that do not access any database tables?
I think that something like select * from pg_stat_activity might not
bump any table-access counters,
On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm not sure I understand the point of this whole thing. Realistically,
how many transactions are there that do not access any database tables?
I think that something like
On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
I'm not sure I understand the point of this whole thing. Realistically,
how many transactions are there that do not access any database tables?
I think that something like
12 matches
Mail list logo
