On Thu, 2005-12-15 at 19:06 -0500, Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Does the backend support, or could it be easily modified to support,
a mechanism that would post the command string after a configurable
amount of time had expired, and then continue processing the
Now there goes Tom with his skeptical eye again, and here comes me
saying oops again. Further tests show that for this application
I made the same mistake, fwiw. The big hit comes with command_string.
However, row level stats bring a big enough penalty (~10% on my usage)
that I keep them
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Further tests show that for this application
the killer is stats_command_string, not stats_block_level or
stats_row_level.
I tried it with pgbench -c 10, and got these results:
41% reduction in TPS rate for
On Mon, Dec 12, 2005 at 10:20:45PM -0500, Tom Lane wrote:
Given the rather lackadaisical way in which the stats collector makes
the data available, it seems like the backends are being much too
enthusiastic about posting their stats_command_string status
immediately. Might be worth thinking
Michael Fuhr [EMAIL PROTECTED] writes:
Does the backend support, or could it be easily modified to support,
a mechanism that would post the command string after a configurable
amount of time had expired, and then continue processing the query?
Not really, unless you want to add the overhead of
Tom Lane wrote:
Michael Fuhr [EMAIL PROTECTED] writes:
Does the backend support, or could it be easily modified to support,
a mechanism that would post the command string after a configurable
amount of time had expired, and then continue processing the query?
Not really, unless you want
Michael Fuhr wrote:
On Sun, Dec 11, 2005 at 11:53:36AM +, Carlos Benkendorf wrote:
I would like to use autovacuum but is not too much expensive
collecting row level statistics?
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant
On Sun, Dec 11, 2005 at 11:53:36AM +, Carlos Benkendorf wrote:
I would like to use autovacuum but is not too much expensive
collecting row level statistics?
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant performance
On Mon, Dec 12, 2005 at 01:33:27PM -0500, Merlin Moncure wrote:
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant performance difference for
simple selects, but a series of insert/update/delete operations ran
about 30% slower when
On Mon, Dec 12, 2005 at 10:23:42AM -0300, Alvaro Herrera wrote:
Michael Fuhr wrote:
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant performance difference for
simple selects, but a series of insert/update/delete operations ran
about
Merlin Moncure [EMAIL PROTECTED] writes:
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant performance difference for
simple selects, but a series of insert/update/delete operations ran
about 30% slower when block- and row-level statistics
On Mon, Dec 12, 2005 at 06:01:01PM -0500, Tom Lane wrote:
IIRC, the only significant cost from enabling stats is the cost of
transmitting the counts to the stats collector, which is a cost
basically paid once at each transaction commit. So short transactions
will definitely have more overhead
Michael Fuhr [EMAIL PROTECTED] writes:
Further tests show that for this application
the killer is stats_command_string, not stats_block_level or
stats_row_level.
I tried it with pgbench -c 10, and got these results:
41% reduction in TPS rate for stats_command_string
9%
Hi,I would like to use autovacuum but is nottoo much expensivecollecting row level statistics?Are there some numbers that I could use?Thanks in advance!Benkendorf
Yahoo! doce lar. Faça do Yahoo! sua homepage.
On Sun, Dec 11, 2005 at 11:53:36AM +, Carlos Benkendorf wrote:
I would like to use autovacuum but is not too much expensive
collecting row level statistics?
The cost depends on your usage patterns. I did tests with one of
my applications and saw no significant performance difference for
15 matches
Mail list logo
