On Wed, Feb 11, 2009 at 11:30 PM, Brad Nicholson
wrote:
> On Wed, 2009-02-11 at 22:57 +0530, Rajesh Kumar Mallah wrote:
>> On Wed, Feb 11, 2009 at 10:03 PM, Grzegorz Jaśkiewicz
>> wrote:
>> > On Wed, Feb 11, 2009 at 2:57 PM, Rajesh Kumar Mallah
>> > wrote:
>> >
>> >>> vacuum_cost_delay = 150
>>
On Wed, 2009-02-11 at 22:57 +0530, Rajesh Kumar Mallah wrote:
> On Wed, Feb 11, 2009 at 10:03 PM, Grzegorz Jaśkiewicz
> wrote:
> > On Wed, Feb 11, 2009 at 2:57 PM, Rajesh Kumar Mallah
> > wrote:
> >
> >>> vacuum_cost_delay = 150
> >>> vacuum_cost_page_hit = 1
> >>> vacuum_cost_page_miss = 10
> >
On Wed, 11 Feb 2009, Scott Carey wrote:
On a large partitioned database, ordinary vacuum is a very very difficult
option.
Most of the time on such a system, most tables are dormant with respect to
writes and never need to be vacuumed. A 'daily vacuum' is likely to take a
full day to run on
On Wed, Feb 11, 2009 at 10:03 PM, Grzegorz Jaśkiewicz wrote:
> On Wed, Feb 11, 2009 at 2:57 PM, Rajesh Kumar Mallah
> wrote:
>
>>> vacuum_cost_delay = 150
>>> vacuum_cost_page_hit = 1
>>> vacuum_cost_page_miss = 10
>>> vacuum_cost_page_dirty = 20
>>> vacuum_cost_limit = 1000
>>> autovacuum_vacuum
On a large partitioned database, ordinary vacuum is a very very difficult
option.
Most of the time on such a system, most tables are dormant with respect to
writes and never need to be vacuumed. A 'daily vacuum' is likely to take a
full day to run on larger systems. Since ordinary vacuum can't
On Feb 11, 2009, at 6:57 AM, Rajesh Kumar Mallah wrote:
why is it not a good idea to give end users control over when they
want to run it ?
There's nothing stopping you from just turning off autovacuum and
running vacuum manually. The point of autovacuum is to vacuum "as
needed."
--
Sen
On Wed, Feb 11, 2009 at 2:57 PM, Rajesh Kumar Mallah
wrote:
>> vacuum_cost_delay = 150
>> vacuum_cost_page_hit = 1
>> vacuum_cost_page_miss = 10
>> vacuum_cost_page_dirty = 20
>> vacuum_cost_limit = 1000
>> autovacuum_vacuum_cost_delay = 300
>
> why is it not a good idea to give end users control
Rajesh Kumar Mallah escribió:
> why is it not a good idea to give end users control over when they
> want to run it ?
It has never been said that we don't want to give the users control.
It's a matter of writing the code. If you want to propose a patch to
add the feature, feel free.
--
Sent vi
On Wed, Feb 11, 2009 at 7:11 PM, Guillaume Cottenceau wrote:
> Rajesh Kumar Mallah writes:
>
>> Hi,
>>
>> Is it possible to configure autovacuum to run only
>> during certain hours ? We are forced to keep
>> it off because it pops up during the peak
>> query hours.
>
> You'd rather configure the
Rajesh Kumar Mallah writes:
> Hi,
>
> Is it possible to configure autovacuum to run only
> during certain hours ? We are forced to keep
> it off because it pops up during the peak
> query hours.
You'd rather configure the delaying process to not alter too much
performance. Autovacuum is really n
> From: Rajesh Kumar Mallah
> Is it possible to configure autovacuum to run only
> during certain hours ? We are forced to keep
> it off because it pops up during the peak
> query hours.
AFAIK not directly within the conf.
However you could probably set up a shell script to turn it on and off
Hi,
Is it possible to configure autovacuum to run only
during certain hours ? We are forced to keep
it off because it pops up during the peak
query hours.
Regds
rajesh kumar mallah.
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscriptio
hurray!
ANALYZING changed the plan
I was not expecting the plan to change because
the partition of 2006_02 is supposed to be
dormant. maybe the partition was never analyzed.
But still question remains, why the time taken was
in orders of magnitude higher in loaded condition.
tradein_clients=>
thanks for the hint,
now the peak hour is over and the same scan is taking 71 ms in place of 8 ms
and the total query time is also acceptable. But it is surprising that
the scan was
taking so long consistently at that point of time. I shall test again
under similar
circumstance tomorrow.
Is i
Both queries are using your uid index on each of the partitions not
generated_date, it's doing the generated_date with a filter on most of the
partitions.
This is except for on partition part_2006_02 in the second query where it uses
your generated date index - and that takes the 80 secs.
Dear friends,
I have explain analyze of two queries
explain analyze SELECT count(*) from general.rfis where 1=1 and
inquiry_type = 'BUY'and receiver_uid=1320721;
(7 ms)
http://pastebin.com/m5297e03c
explain analyze SELECT count(*) from general.rfis where 1=1 and
inquiry_type = 'BUY'
16 matches
Mail list logo
