\On Jul 29, 2007, at 9:37 AM, Tom Lane wrote:
Erik Jones <[EMAIL PROTECTED]> writes:
improvement that went into that release. I could test turning it
back on this week if you like -- I certainly would like to have my
blks_read/cach_hits stats back. Toggling stats_block_level will
respond to a
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Methinks it should be: stats_, so that people find it in the
> >> same place as stats_query_string, which is still there.
>
> > Hum, but the order in postgresql.conf is arbitrary, right?
>
> I concur with Sim
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Or we could get radical and rename both of them...
>
>> Well, it is a bit misleading to have the query_string stuff be named
>> "stats" when it's not actually collected by pgstats at all. Ma
Alvaro Herrera wrote:
> Well, it is a bit misleading to have the query_string stuff be named
> "stats" when it's not actually collected by pgstats at all.
By now, the statistics collector is unnoticeable to most users, since
it's always on and you never have to do anything about it. The fact
th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Or we could get radical and rename both of them...
> Well, it is a bit misleading to have the query_string stuff be named
> "stats" when it's not actually collected by pgstats at all. Maybe
> rename it to "collect_query_string". Wit
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> Methinks it should be: stats_, so that people find it in the
> >> same place as stats_query_string, which is still there.
>
> > Hum, but the order in postgresql.conf is arbitrary, right?
>
> I concur with Sim
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > FWIW I just noticed we have a variable named "krb_caseins_users" which I
> > think is not such a great name for it. Prolly best to change it now
> > while it's still in the oven.
>
> You're two releases too late for that one :-(
Do
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> FWIW I just noticed we have a variable named "krb_caseins_users" which I
> think is not such a great name for it. Prolly best to change it now
> while it's still in the oven.
You're two releases too late for that one :-(
regard
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Methinks it should be: stats_, so that people find it in the
>> same place as stats_query_string, which is still there.
> Hum, but the order in postgresql.conf is arbitrary, right?
I concur with Simon that it should have some rela
On Tue, 2007-07-31 at 13:06 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> > > Tom Lane wrote:
> > > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > > I agree. Let's remove stats_start_collector and merge the other two
> > > >
Simon Riggs wrote:
> On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> > Tom Lane wrote:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > I agree. Let's remove stats_start_collector and merge the other two
> > > > into a single setting. Anything more than that is overkill.
> > >
On Tue, 2007-07-31 at 12:33 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > I agree. Let's remove stats_start_collector and merge the other two
> > > into a single setting. Anything more than that is overkill.
> >
> > So what are we going to ca
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I agree. Let's remove stats_start_collector and merge the other two
> > into a single setting. Anything more than that is overkill.
>
> So what are we going to call the one surviving GUC variable?
"collect_stats"
--
Alvaro Herre
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I agree. Let's remove stats_start_collector and merge the other two
> into a single setting. Anything more than that is overkill.
So what are we going to call the one surviving GUC variable?
regards, tom lane
Erik Jones <[EMAIL PROTECTED]> writes:
> improvement that went into that release. I could test turning it
> back on this week if you like -- I certainly would like to have my
> blks_read/cach_hits stats back. Toggling stats_block_level will
> respond to a reload, yes?
Yes, as long as you h
On Jul 27, 2007, at 6:45 PM, Jim Nasby wrote:
On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
So maybe the *real* question to ask is why we have separate GUCs for
stats_row_level and stats_block_level. Shouldn't we fold them into a
single switch? It's hard to see what having just one of them
t
On Jul 26, 2007, at 2:03 PM, Tom Lane wrote:
So maybe the *real* question to ask is why we have separate GUCs for
stats_row_level and stats_block_level. Shouldn't we fold them into a
single switch? It's hard to see what having just one of them
turned on
will save.
IIRC, the guys at Emma ha
On Fri, 2007-07-27 at 10:15 +0100, Dave Page wrote:
> Simon Riggs wrote:
> > On Fri, 2007-07-27 at 04:29 -0400, Alvaro Herrera wrote:
> >> Peter Eisentraut wrote:
> >>> Tom Lane wrote:
> > Any reason not to just fold them both into stats_start_collector ?
> Well, then you couldn't turn col
Simon Riggs wrote:
> On Fri, 2007-07-27 at 04:29 -0400, Alvaro Herrera wrote:
>> Peter Eisentraut wrote:
>>> Tom Lane wrote:
> Any reason not to just fold them both into stats_start_collector ?
Well, then you couldn't turn collection on and off without restarting
the postmaster, which
On Fri, 2007-07-27 at 04:29 -0400, Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > Tom Lane wrote:
> > > > Any reason not to just fold them both into stats_start_collector ?
> > >
> > > Well, then you couldn't turn collection on and off without restarting
> > > the postmaster, which might be a
Peter Eisentraut wrote:
> Tom Lane wrote:
> > > Any reason not to just fold them both into stats_start_collector ?
> >
> > Well, then you couldn't turn collection on and off without restarting
> > the postmaster, which might be a pain.
>
> Maybe we don't actually need stats_start_collector, but in
Tom Lane wrote:
> > Any reason not to just fold them both into stats_start_collector ?
>
> Well, then you couldn't turn collection on and off without restarting
> the postmaster, which might be a pain.
Maybe we don't actually need stats_start_collector, but instead we start
it always and just hav
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> I think the stats stuff should be on by default even if it causes
> some performance penalty.
> Because when we have performance problems on the production system,
> it needs more performance penalty (about 5%~) to measure the stats
> by turning their
Tom,
>> Yes. It's pure overhead with no redeeming social value except to those
>> who actually want to look at that sort of stat, and those who do can
>> certainly turn it on for themselves.
I think the stats stuff should be on by default even if it causes
some performance penalty.
Because when
Tom Lane wrote:
> I wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> Anybody got any objection to setting it on by default?
>
> > Yes. It's pure overhead with no redeeming social value except to those
> > who actually want to look at that sort of stat, and those who do can
> > certainly
Dave Page <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So maybe the *real* question to ask is why we have separate GUCs for
>> stats_row_level and stats_block_level. Shouldn't we fold them into a
>> single switch? It's hard to see what having just one of them turned on
>> will save.
> Any re
Tom Lane wrote:
> So maybe the *real* question to ask is why we have separate GUCs for
> stats_row_level and stats_block_level. Shouldn't we fold them into a
> single switch? It's hard to see what having just one of them turned on
> will save.
Any reason not to just fold them both into stats_st
I wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Anybody got any objection to setting it on by default?
> Yes. It's pure overhead with no redeeming social value except to those
> who actually want to look at that sort of stat, and those who do can
> certainly turn it on for themselves.
On
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Anybody got any objection to setting it on by default?
Yes. It's pure overhead with no redeeming social value except to those
who actually want to look at that sort of stat, and those who do can
certainly turn it on for themselves.
Why is stats_block_level = off by default?
Is there a measurable cost to enabling this? We already have
stats_row_level = on, so presumably the overhead of setting
stats_block_level to on cannot be any worse than that.
Anybody got any objection to setting it on by default?
--
Simon Riggs
En
30 matches
Mail list logo
