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
>
>
>
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 |
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) |