Re: database tuning

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: database tuning
Дата
Msg-id 475D8257.EE98.0025.0@wicourts.gov
обсуждение исходный текст
Ответ на Re: database tuning  ("kelvan" <kicmcewen@windowslive.com>)
Список pgsql-performance
>>> On Mon, Dec 10, 2007 at  6:29 PM, in message <fjki5a$uf1$1@news.hub.org>,
"kelvan" <kicmcewen@windowslive.com> wrote:

> i need a more powerful dbms one that can
> handle multi threading.

If you're looking to handle a lot of concurrent users, PostgreSQL
has the power.  The threading issues really only impact the ability
to spread the work for a single large query over the processors.
For multiple users the work is spread over the processors just fine.

> as i have said not my choice i know 5 gigs of ram wouldnt start a hot air
> balloon let alone support the user base i will have

We've run a web site with two million hits per day, running 10
million SELECT queries and 1 million DML database transactions
(averaging over 10 million DML statements) per day on a machine
with 6 MB of RAM under PostgreSQL, so you might be surprised.
Your biggest problem is the single disk drive.  RAID not only
is critical for data integrity, it helps performance when your
data is not fully cached.

> we cannot configure postgres on a mac to
> go over 200 connections for god knows what reason but we have found ways
> around that using the mac

Well, with four processors there's no point to going above about
15 or 20 database connections.  Use one of the many excellent
options for connection pooling for better results.

> i am using alot of codes using small int and bit in my database and
> de-normalising everying to keep the cnnections down and the data read
> ammount down but that can only do so much.

Denormalization almost always requires more disk space.  That's
exactly what you should be trying to avoid.

> my problem is read time which is why i want to compact the postgres blocks
> as much as possible keeping the data of the database in as small a location
> as possible.

A much bigger issue from that regard will probably be dead space
from updated and deleted rows (plus from any rollbacks).  Have
you figured out what your VACUUM strategy will be?

Without knowing more, it's hard to say for sure, but you might do
just fine if you can get a few more drives hooked up through a
decent RAID controller, and funnel your connection through a
connection pool.

I hope this helps.

-Kevin



В списке pgsql-performance по дате отправления:

Предыдущее
От: "kelvan"
Дата:
Сообщение: Re: database tuning
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Fwd: Re: database tuning