On Fri, 2011-06-03 at 11:07 -0700, Michael Holt wrote:
> I'm investigating moving from slony to streaming replication as we
> plan some upgrades from 8.x versions of postgres to 9. I've managed to
> get it working but there's a couple questions I've been unable to find
> answers to so far.
>
> 1)
I'm investigating moving from slony to streaming replication as we plan some
upgrades from 8.x versions of postgres to 9. I've managed to get it working
but there's a couple questions I've been unable to find answers to so far.
1) I've seen things about using pg_current_xlog_location(),
pg_last_xl
Mark Stosberg writes:
> Compared to 1669 MB reported as table bloat in the 'bloat' view. So,
> the bloat is about 40% of the total size.
> For an index, it's 410 MB of bloat, vs 1669 MB for an index size.
Hm ... 40% unused space wouldn't be surprising at all for an index.
The traditional rule of
Thanks for reply, Tom.
> It's hard to evaluate that without knowing what the actual table/index
> sizes are, or IOW what is the reported bloat on a percentage basis?
The table size is reported as: 4036 MB according to:
select pg_size_pretty(pg_table_size('table_name'));
Compared to 1669 MB
Brett,
Thanks! That did it.
Lance
-Original Message-
From: pgsql-admin-ow...@postgresql.org
[mailto:pgsql-admin-ow...@postgresql.org] On Behalf Of Brett Parker
Sent: Friday, June 03, 2011 8:32 AM
To: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] viewing results in terminal on RedHat 6
Mark Stosberg writes:
> I recently set up partitioning on a table that sees heavy insert
> traffic. There are never updates or deletes, we just drop the partitions
> later.
> It's my understanding that bloat can only appear through updates or
> deletes, but these partitions are reported to have s
I recently set up partitioning on a table that sees heavy insert
traffic. There are never updates or deletes, we just drop the partitions
later.
It's my understanding that bloat can only appear through updates or
deletes, but these partitions are reported to have significant bloat in
them. Where
I am in the process of implementing cascade on delete constraints
retroactively on rather large tables so I can cleanly remove deprecated
data. The problem is recreating some foreign key constraints on tables of
55 million rows+ was taking much longer than the maintenance window I had,
and now I a
On 03 Jun 12:49, Campbell, Lance wrote:
> Postgres: 9.x
> On RedHat 4.x when I would access Postgres through a terminal for command
> line queries if the results of a queries exceeded more than 50+ lines I would
> still see the results after pressing "quit". On RedHat 6.1 Workstation when
> I s
fel wrote:
> I have a small server running RHEL 5.2 32bit / Postgresql 8.3.3.
> I would like to upgrade Postgres to 9.0 on a new server running
> RHEL 5.5 but 64bit.
>
> What would be the best solution :
> - Dump data from 32bit to 64bit then upgrade to v9.0 (using
> pg_upgrade).
> - Upgrade
Postgres: 9.x
On RedHat 4.x when I would access Postgres through a terminal for command line
queries if the results of a queries exceeded more than 50+ lines I would still
see the results after pressing "quit". On RedHat 6.1 Workstation when I see
queries that exceed some threshold 50+ when I p
Hello all,
I would need advice regarding upgrade.
I have a small server running RHEL 5.2 32bit / Postgresql 8.3.3.
I would like to upgrade Postgres to 9.0 on a new server running RHEL 5.5
but 64bit.
What would be the best solution :
- Dump data from 32bit to 64bit then upgrade to v9.0 (using
12 matches
Mail list logo
