Re: [HACKERS] []performance issues

From: "Peter A(dot) Daly" <petedaly(at)ix(dot)netcom(dot)com>
To: PostgreSQL general list <pgsql-general(at)postgresql(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] []performance issues
Date: 2002-08-05 17:22:20
Message-ID: 3D4EB44C.9020503@ix.netcom.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

We have tables of over 3.1 million records. Performance is fine for most
things as long as access hits an index. As already stated, count(*)
takes a long time. Just took over a minute for me to check the record
count. Our DB is primarily a data warehouse role. Creating an index on a
char(43) field on that table from scratch takes a while, but I think
that's expected. Under normal loads we have well under 1 second "LIKE"
queries on that the indexed char(43) field in the table with a join on a
table of 1.1 million records using a char(12) primary key.

Server is a Dell PowerEdge 2400, Dual PIII 667's with a gig of memory,
800 something megs allocated to postgres shared buffers.

-Pete

Andrew Sullivan wrote:

>On Fri, Aug 02, 2002 at 03:48:39PM +0400, Yaroslav Dmitriev wrote:
>
>
>>So I am still interested in PostgreSQL's ability to deal with
>>multimillon records tables.
>>
>>
>
>[x-posted and Reply-To: to -general; this isn't a development
>problem.]
>
>We have tables with multimillion records, and they are fast. But not
>fast to count(). The MVCC design of PostgreSQL will give you very
>few concurerncy problems, but you pay for that in the response time
>of certain kinds of aggregates, which cannot use an index.
>
>A
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2002-08-05 17:24:49 Re: psql client
Previous Message Nigel J. Andrews 2002-08-05 17:04:28 Re: Memory usage / concept

Browse pgsql-hackers by date

  From Date Subject
Next Message Hans-Jürgen Schönig 2002-08-05 17:25:05 Feature Request: Optimizer tuning
Previous Message John Gray 2002-08-05 17:21:54 Current CVS build fails in src/backend/utils/mb/conversion_procs (VPATH)