Dear Folks,
On 24/07/07 05:31 +1000, Nick Urbanik wrote:
Dear Jim,
On 15/05/07 20:28 -0500, Jim C. Nasby wrote:
On Wed, May 16, 2007 at 11:20:52AM +1000, Nick Urbanik wrote:
Dear Alvaro,
On 15/05/07 21:12 -0400, Alvaro Herrera wrote:
>Nick Urbanik wrote:
>>On 15/05/07 18:53 -0400, Alvaro Her
Dear Jim,
On 15/05/07 20:28 -0500, Jim C. Nasby wrote:
On Wed, May 16, 2007 at 11:20:52AM +1000, Nick Urbanik wrote:
Dear Alvaro,
On 15/05/07 21:12 -0400, Alvaro Herrera wrote:
>Nick Urbanik wrote:
>>On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
>You probably need to better configure the FSM
Dear Folks,
I am running a full vacuum on a database. It's taking longer than I
hoped. In particular, the vacuum still hasn't reached the table that
will benefit most from the vacuum.
Can I move the existing table to a backup, make a copy of the table
back to its original name, restart the app
On Wed, May 16, 2007 at 11:20:52AM +1000, Nick Urbanik wrote:
> Dear Alvaro,
>
> On 15/05/07 21:12 -0400, Alvaro Herrera wrote:
> >Nick Urbanik wrote:
> >>On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
> >>>Instead of waiting a month for the time when you can take the
> >>>application offline (thu
Dear Alvaro,
On 15/05/07 21:12 -0400, Alvaro Herrera wrote:
Nick Urbanik wrote:
On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
>Instead of waiting a month for the time when you can take the
>application offline (thus accumulating a month's worth of dead tuples),
>run a non-full vacuum more ofte
Nick Urbanik wrote:
> Thank you Alvaro,
>
> On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
> >Instead of waiting a month for the time when you can take the
> >application offline (thus accumulating a month's worth of dead tuples),
> >run a non-full vacuum more often (say, once a day or more). It
Now add primary key, indices, foreign keys, triggers, rules, column
defaults to mytable, and you'll probably want to drop the foreign keys
at least from mytable_old. I'm afraid you'll have to sort out manually
what these should be.
*/
7.3.8 is quite seriously old. 7.3.19 is the latest in tha
Nick Urbanik wrote:
It seems that PostgreSQL 7.3.8 does not support create table
table_name like original_table.
Can you suggest a way I can create a duplicate table with the same
triggers and other stuff that this table has?
What is the most efficient way to copy the data?
Something like:
Thank you Geoff,
On 15/05/07 16:11 -0700, Geoff Tolley wrote:
Nick Urbanik wrote:
If you're waiting on vacuum to get around to the one table, you can run
VACUUM FULL instead.
Clearly that is what I should have done! It has reached the table now.
Personally I've found that dropping indices
Thank you Alvaro,
On 15/05/07 18:53 -0400, Alvaro Herrera wrote:
Instead of waiting a month for the time when you can take the
application offline (thus accumulating a month's worth of dead tuples),
run a non-full vacuum more often (say, once a day or more). It doesn't
lock the table so the app
Nick Urbanik wrote:
I am running a full vacuum on a database. It's taking longer than I
hoped. In particular, the vacuum still hasn't reached the table that
will benefit most from the vacuum.
Can I move the existing table to a backup, make a copy of the table
back to its original name, restar
Nick Urbanik wrote:
> Dear Folks,
>
> I am running a full vacuum on a database. It's taking longer than I
> hoped. In particular, the vacuum still hasn't reached the table that
> will benefit most from the vacuum.
>
> Can I move the existing table to a backup, make a copy of the table
> back to
12 matches
Mail list logo
