>>>>> "MGF" == Marc G Fournier <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
