From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | mark durrant <markd89(at)yahoo(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Select performance vs. mssql |
Date: | 2005-05-25 01:29:36 |
Message-ID: | 4293D500.8010908@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> --As Chris pointed out, how real-world is this test?
> His point is valid. The database we're planning will
> have a lot of rows and require a lot of summarization
> (hence my attempt at a "test"), but we shouldn't be
> pulling a million rows at a time.
If you want to do lots of aggregate analysis, I suggest you create a
sepearate summary table, and create triggers on the main table to
maintain your summaries in the other table...
> --MSSQL's ability to hit the index only and not having
> to go to the table itself results in a _big_
> performance/efficiency gain. If someone who's in
> development wants to pass this along, it would be a
> nice addition to PostgreSQL sometime in the future.
> I'd suspect that as well as making one query faster,
> it would make everything else faster/more scalable as
> the server load is so much less.
This is well-known and many databases do it. However, due to MVCC
considerations in PostgreSQL, it's not feasible for us to implement it...
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | SpaceBallOne | 2005-05-25 02:07:49 | Can anyone explain this: duplicate dbs. |
Previous Message | John A Meinel | 2005-05-25 00:38:08 | Re: Select performance vs. mssql |