On Mon, Dec 5, 2011 at 11:08 AM, Bruce Momjian wrote:
>
> If you look in a 9.0+ tablespace directory, you will see that each
> cluster has its own subdirectory:
>
> test=> create tablespace tb1 location '/u/pg/tb1';
> CREATE TABLESPACE
> test=> \q
> $ lf /u/pg/tb1
>
On Mon, Dec 5, 2011 at 11:36 AM, Kevin Grittner
wrote:
> Ernesto Quiñones wrote:
>> vacuum_cost_limit 200
> We've boosted this to 600. Once you're in a "steady state", this is
> the setting you might want to adjust up or down as needed to make
> cleanup aggressive enough without putting a notic
Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue wrote:
> > On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
> >>> But initial response to all this, is umm we have not really made a
> >>> dump/restore unnecessary with the latest releases of Postgres than, as
> >>> I would ha
Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
> >> But initial response to all this, is umm we have not really made a
> >> dump/restore unnecessary with the latest releases of Postgres than, as
> >> I would have to think that there is a high percentage of users whom
>
On Mon, Dec 5, 2011 at 10:31 AM, Tory M Blue wrote:
> On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
>>> But initial response to all this, is umm we have not really made a
>>> dump/restore unnecessary with the latest releases of Postgres than, as
>>> I would have to think that there is a h
Ernesto Quiñones wrote:
I understand the impulse to run autovacuum less frequently or less
aggressively. When we first started running PostgreSQL the default
configuration was very cautious. A lot of bloat would accumulate
before it kicked in, at which point there was a noticeable
performance h
On Mon, Dec 5, 2011 at 10:22 AM, Bruce Momjian wrote:
>> But initial response to all this, is umm we have not really made a
>> dump/restore unnecessary with the latest releases of Postgres than, as
>> I would have to think that there is a high percentage of users whom
>> use tablespaces.
>
> Yes,
Tory M Blue wrote:
> Bruce is right, I didn't move tablespaces (I didn't know to be honest
> I had to, but it makes sense). I simply moved the location of the data
> files, from /data to /data1. But I did "not", change any sym links or
I was unclear if you moved the data directory or the tablespac
no problem Scott, thanks for your appreciations
2011/12/5 Scott Marlowe :
> On Mon, Dec 5, 2011 at 10:42 AM, Scott Marlowe
> wrote:
>> On Mon, Dec 5, 2011 at 10:19 AM, Ernesto Quiñones wrote:
>>> vacuum_cost_delay 1s
>>> vacuum_cost_limit 200
>>
>> Those are insane settings for va
On Mon, Dec 5, 2011 at 10:42 AM, Scott Marlowe wrote:
> On Mon, Dec 5, 2011 at 10:19 AM, Ernesto Quiñones wrote:
>> vacuum_cost_delay 1s
>> vacuum_cost_limit 200
>
> Those are insane settings for vacuum costing, even on a very slow
> machine. Basically you're starving vacuum and auto
On Mon, Dec 5, 2011 at 10:19 AM, Ernesto Quiñones wrote:
> Hi Kevin, comments after your comments
>
> 2011/12/3 Kevin Grittner :
>> Ernesto Quiñones wrote:
>>> Scott Marlowe wrote:
Ernesto Quiñones wrote:
>>
> I want to know if it's possible to predict (calculate), how long
> a VACU
On Mon, Dec 5, 2011 at 7:34 AM, Bruce Momjian wrote:
> Nicholson, Brad (Toronto, ON, CA) wrote:
>>
>> Based on the OP this does not seem like a messed up configuration. It
>> sounds like the OP used a fully supported core feature of Postgres
>> (tablespaces) and pg_upgrade failed as a result. I
Hi Kevin, comments after your comments
2011/12/3 Kevin Grittner :
> Ernesto Quiñones wrote:
>> Scott Marlowe wrote:
>>> Ernesto Quiñones wrote:
>
I want to know if it's possible to predict (calculate), how long
a VACUUM FULL process will consume in a table?
>
> I don't think you said w
Nicholson, Brad (Toronto, ON, CA) wrote:
> > -Original Message-
> > From: Bruce Momjian [mailto:br...@momjian.us]
> > Sent: Monday, December 05, 2011 10:24 AM
> > To: Nicholson, Brad (Toronto, ON, CA)
> > Cc: Tory M Blue; pgsql-performance@postgresql.org; Magnus Hagander
> > Subject: Re: [P
> -Original Message-
> From: Bruce Momjian [mailto:br...@momjian.us]
> Sent: Monday, December 05, 2011 10:24 AM
> To: Nicholson, Brad (Toronto, ON, CA)
> Cc: Tory M Blue; pgsql-performance@postgresql.org; Magnus Hagander
> Subject: Re: [PERFORM] pg_upgrade
>
> Nicholson, Brad (Toronto, ON,
Nicholson, Brad (Toronto, ON, CA) wrote:
> > You mean moving tablespaces? That isn't something pg_upgrade deals
> > with. If we need docs to move tablespaces, it is a missing piece of
> > our
> > main docs, not something pg_upgrade would ever mention.
>
> If I'm reading the issue correctly, and
Thiago Godoi wrote:
> Thanks for the answers.
>
> I found one of these cases , but I'm trying to understand this. Why the
> performance is better? The number of tuples is making the difference?
>
> My original query :
>
> select table1.id
> from table1, (select function(12345) id) table2
> where
> -Original Message-
> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-
> ow...@postgresql.org] On Behalf Of Bruce Momjian
> Sent: Saturday, December 03, 2011 6:42 PM
> To: Tory M Blue
> Cc: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] pg_upgrade
>
> T
Thanks for the answers.
I found one of these cases , but I'm trying to understand this. Why the
performance is better? The number of tuples is making the difference?
My original query :
select table1.id
from table1, (select function(12345) id) table2
where table1.kind = 1234
and table1.id = tabl
19 matches
Mail list logo
