Tsearch2 index size - Mailing list pgsql-hackers

From richard-pgodbc@armchair.mb.ca
Subject Tsearch2 index size
Date
Msg-id cone.1161630166.791204.11114.1000@oldbob
Whole thread Raw
Responses Re: Tsearch2 index size
List pgsql-hackers
I am running versions 8.1.2 and I installed 8.2B last week.  I dumped 
the data from the old version into the new version. The db consists of 
several million records.  Total disk usage is approximately 114GB.

My two observations are as follows... Also, keep in mind these are truly 
just observations, I didn't use any benchmarking tools.  If someone can 
point me to a link of performance tools, I'd be happy to try them and report 
back!

1. The release notes indicate "more efficient vacuuming."  However, both 
vacuums seems to take about the same amount of time, ie. approx: 9 hours.  
Does "more efficient" simply mean, less IO/CPU busyness?  This one doesn't 
really bother me, the next one does...

Here are my vacuum parms, I used the same ones for both versions, of 
course.
----------
maintenance_work_mem = 400000 # Unnecessarily high, I know.... I left it                             # for comparison's
sake.
vacuum_cost_delay = 50
vacuum_cost_page_hit = 1
vacuum_cost_page_miss = 10
vacuum_cost_page_dirty = 20
vacuum_cost_limit = 2000
----------



2. I have a tsearch2 index which is 756MB in size in 8.1.2 but balloons to 
910MB in 8.2!  These numbers were taken right after a REINDEX.  Normally, I 
wouldn't care about physical index size, but this particular index is 
sitting on a ramdisk, so size really does matter.  I see that the tsearch2 
type was diddled with in 8.2.  Is this an intentional change to improve 
tsearch2 performance?

Thank you for any advice or abuse you give.  No.  Wait.  No abuse please.

Richard Whidden


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] smartvacuum() instead of autovacuum
Next
From: Tom Lane
Date:
Subject: Re: New CRC algorithm: Slicing by 8