>>>>> "MGF" == Marc G Fournier <scrappy@hub.org> writes:
MGF> Just curious, but Bruce(?) mentioned that apparently a 32k block size was
MGF> found to show a 15% improvement ... care to run one more test? :)
Well, it is hard to tell based on my quick and dirty test:
16k page size:
restore time: 11322 seconds
vacuum analyze time: 1663 seconds (27 minutes)
select count(*) from user_list where owner_id=315; 56666.64 ms
32k page size:
restore time: 11430 seconds
vacuum analyze time: 1346 seconds
select count(*) from user_list where owner_id=315; 63275.73 ms
one anomaly I note is that if I re-run the select count(*) query
above, the large the page size, the longer the query takes. In the
standard 8k page size, it was on the order of 306ms, with 16k page
size it was over 1400, and with 32k page size nearly 3000ms.
Another anomaly I note is that for the larger indexes, the relpages
doesn't scale as expected. ie, I'd expect roughly half the relpages
per index for 32k page size as for 16k page size, but this is not
always the case... some are about the same size and some are about 2/3
and some are about 1/2. The smaller indexes are often the same number
of pages (when under 20 pages).
I think I'm going to write a synthetic load generator that does a
bunch of inserts to some linked tables with several indexes, then goes
thru and pounds on it (update/select) from multiple children with
occasional vacuum's thrown in. That's the only way to get 'real'
numbers, it seems.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
