Le 03/12/2010 16:19, Little, Douglas a écrit :
>
>
> Sorry, outlook must of clobbered the table.
>
> [cid:image001.png@01CB92CB.11EA5F60]
>
>
>
> Pg_attribute has 513871 tuples and should take up 2135 pages. It's
> currently allocated to 98646 pages.
>
> Given that much bloat, what woul
Le 03/12/2010 16:28, Little, Douglas a écrit :
> Somehow this moved to the pgadmin list. It was intended for pgsql-admin. My
> apologies.
> This is a dba task, I'd never expect pgadmin would do this.
>
It didn't *move* to the pgadmin list, your first mail was sent there.
pgAdmin doesn't do it
Le 03/12/2010 16:24, Little, Douglas a écrit :
> Michael,
>
> I hear that vacuum full shouldn't be used.
> But what impact does the bloat have on performance?
Bigger on your hard, so slower to scan. And bigger in memory, so you
need to push blocks out to scan it. Other than that, not much.
It's
Le 03/12/2010 16:25, Michael Shapiro a écrit :
> I understand, but in this case, since the option is offered next to the safe
> one, most people won't know it isn't safe.
Both are safe. They don't offer the same service. VACUUM will allow
PostgreSQL to reuse dead space, VACUUM FULL will free space
Admin Support
Subject: Re: [pgadmin-support] fsm and vacuum
I understand, but in this case, since the option is offered next to the safe
one, most people won't know it isn't safe.
I certainly didn't until I read this posting. I know generally what vacuuming
does, but I had no idea tha
I understand, but in this case, since the option is offered next to the safe
one, most people won't know it isn't safe.
I certainly didn't until I read this posting. I know generally what
vacuuming does, but I had no idea that postgres offered a potentially
damaging option. Also, PgAdmin sometimes
Le 03/12/2010 15:17, Michael Shapiro a écrit :
> The document http://wiki.postgresql.org/wiki/VACUUM_FULL says:
>
> VACUUM FULL, unlike VACUUM, tuples data that has not been deleted, moving it
> into spaces earlier in the file that have been freed. Once it's created a
> free space at the end of th
The document http://wiki.postgresql.org/wiki/VACUUM_FULL says:
VACUUM FULL, unlike VACUUM, tuples data that has not been deleted, moving it
into spaces earlier in the file that have been freed. Once it's created a
free space at the end of the file, it truncates the file so that the OS
knows that s
Le 03/12/2010 14:40, Little, Douglas a écrit :
> [...]
> Given this syscat bloat, what would you recommend doing?
>
Sorry but that's really unreadable.
--
Guillaume
http://www.postgresql.fr
http://dalibo.com
--
Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org)
To make
] fsm and vacuum
Hi,
Le 03/12/2010 00:19, Little, Douglas a écrit :
> [...]
> Thanks for the response.
No problem, but keep your anwser to the list, even if it's not the good
one :)
> Still a bit confused.
> Q: The guk settings max_fsm_relations/pages are used by the
Hi,
Le 03/12/2010 00:19, Little, Douglas a écrit :
> [...]
> Thanks for the response.
No problem, but keep your anwser to the list, even if it's not the good
one :)
> Still a bit confused.
> Q: The guk settings max_fsm_relations/pages are used by the db engine to set
> the size of the freespac
Le 02/12/2010 22:00, Little, Douglas a écrit :
> We're new to Greenplum, based on PG (8.2.13). we weren't advised to increase
> the max_fsm_relations switch as our db has grown.
> Currently we're nearly 14k tables/indexes and the switch is set to 1000.
> We've got it updated now, but wondering ab
We're new to Greenplum, based on PG (8.2.13). we weren't advised to increase
the max_fsm_relations switch as our db has grown.
Currently we're nearly 14k tables/indexes and the switch is set to 1000.
We've got it updated now, but wondering about the effect & recovery.
We've regularly been reload
13 matches
Mail list logo
