Re: large tables and simple "= constant" queries using indexes
От | Matthew |
---|---|
Тема | Re: large tables and simple "= constant" queries using indexes |
Дата | |
Msg-id | Pine.LNX.4.64.0804101042050.20402@aragorn.flymine.org обсуждение исходный текст |
Ответ на | Re: large tables and simple "= constant" queries using indexes (PFC <lists@peufeu.com>) |
Ответы |
Re: large tables and simple "= constant" queries using
indexes
|
Список | pgsql-performance |
On Thu, 10 Apr 2008, PFC wrote: ... Lots of useful advice ... > - If you often query rows with the same gene_ref, consider using > CLUSTER to physically group those rows on disk. This way you can get all rows > with the same gene_ref in 1 seek instead of 2000. Clustered tables also make > Bitmap scan happy. In my opinion this is the one that will make the most difference. You will need to run: CLUSTER gene_prediction_view USING gene_prediction_view_gene_ref_key; after you insert significant amounts of data into the table. This re-orders the table according to the index, but new data is always written out of order, so after adding lots more data the table will need to be re-clustered again. > - Switch to a RAID10 (4 times the IOs per second, however zero gain if > you're single-threaded, but massive gain when concurrent) Greg Stark has a patch in the pipeline that will change this, for bitmap index scans, by using fadvise(), so a single thread can utilise multiple discs in a RAID array. Matthew -- Prolog doesn't have enough parentheses. -- Computer Science Lecturer
В списке pgsql-performance по дате отправления: