Re: Speed Question
От | Manfred Koizar |
---|---|
Тема | Re: Speed Question |
Дата | |
Msg-id | 04k80vsfcspvni82kmqkj8qodrh3qbmthq@4ax.com обсуждение исходный текст |
Ответ на | Re: Speed Question (Noah Silverman <noah@allresearch.com>) |
Ответы |
Re: Speed Question
|
Список | pgsql-performance |
On Fri, 20 Dec 2002 19:10:49 -0500, Noah Silverman <noah@allresearch.com> wrote: >Now we are creating more of a real world example: 10MM rows with 32 >columns of integers. I'm loading up the data now, and will create a >multi-column index(on all 32) after the data is loaded. If a table with a 32 column key and no dependent attributes is a real world example, I'd like to see your use case ;-) An index on c1, c2, ..., cn will only help, if your search criteria contain (strict) conditions on the leading index columns, e.g. WHERE c1 = ... AND c2 = ... AND c3 BETWEEN ... AND ... It won't help for WHERE c22 = ... > From everyone's responses I understand that we really need to tune [...] >2x AMD 2100MP CPU >2 GB RAM >Data - 350GB on a raid5 card It all depends on your application, but looking at SHARED_BUFFERS, EFFECTIVE_CACHE_SIZE, SORT_MEM, MAX_FSM_RELATIONS, and MAX_FSM_PAGES might be a good start. Later you might want to use CPU_*_COST, RANDOM_PAGE_COST, and various WAL settings to fine tune your system. >Note: We will probably NEVER use transactions, Oh yes, you will. You have no other choice. If you don't enclose (several) statements between BEGIN and COMMIT, every statement is automatically wrapped into its own transaction. It helps performance and consistency, if *you* control transactions. Servus Manfred
В списке pgsql-performance по дате отправления: