Guillaume,


Given this syscat bloat, what would you recommend doing?


schemaname

tablename

reltuples

relpages

otta

tbloat

wastedpages

wastedbytes

wastedsize

pg_catalog

pg_exttable

7092

3137

49

64

3088

101187584

97 MB

pg_catalog

pg_shdepend

48674

2349

84

28

2265

74219520

71 MB

pg_catalog

pg_shdepend

48674

2349

84

28

2265

74219520

71 MB

pg_catalog

gp_distribution_policy

19810

2131

38

56.1

2093

68583424

65 MB

pg_catalog

pg_class

33044

10139

235

43.1

9904

324534272

310 MB

pg_catalog

pg_class

33044

10139

235

43.1

9904

324534272

310 MB

pg_catalog

pg_attribute

513871

98646

2135

46.2

96511

3162472448

3016 MB




Thanks

Doug





-----Original Message-----
From: Guillaume Lelarge [mailto:guilla...@lelarge.info]
Sent: Friday, December 03, 2010 2:55 AM
To: Little, Douglas
Cc: PgAdmin Support
Subject: Re: [pgadmin-support] 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 db engine to set 
> the size of the freespace map.



In memory, yes.



> Q: vacuum scans thru the file and adds free slots to the map when a table is 
> vacuumed



Yes.



> Q: the map is used by the engine when inserting a row (new or versioned).



Yes.



> So is the only way to initialize the fsm to run vacuum?



Yes.



> We're experiencing problems using vacuum full.  GP recommends 
> ctas/truncate/reload as alternative.

> Obviously won't work for system tables.

> My thought is vacuum full isn't working because the fsm was undersized.



vacuum full first scans the whole table to find free space, and then

scans backward to move every still-in-use space at the beginning of the

table. I don't know if vacuum full puts its information in the fsm, but

I believe so. So, if the fsm is undersized, you risk to have a not fully

effective vacuum full.



Anyway, you should probably not use vacuum full, unless you have a

*really* good reason.



Remember to REINDEX after your VACUUM FULL. Meaning you should probably

use CLUSTER, which will be fully effective and quicker. But you need an

index.



> Anything in the developers docs that would help me understand how it works?



This could be of interest:



  http://wiki.postgresql.org/wiki/VACUUM_FULL





--

Guillaume

http://www.postgresql.fr

http://dalibo.com

Reply via email to