Skip site navigation (1) Skip section navigation (2)

Re: Speed Question

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: Noah Silverman <noah(at)allresearch(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Speed Question
Date: 2002-12-21 12:21:31
Message-ID: 04k80vsfcspvni82kmqkj8qodrh3qbmthq@4ax.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Fri, 20 Dec 2002 19:10:49 -0500, Noah Silverman
<noah(at)allresearch(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Noah SilvermanDate: 2002-12-21 18:46:05
Subject: Re: Speed Question
Previous:From: Philip HallstromDate: 2002-12-21 01:01:13
Subject: Re: Speed Question

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group