> --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...
In response to
pgsql-performance by date
|Next:||From: SpaceBallOne||Date: 2005-05-25 02:07:49|
|Subject: Can anyone explain this: duplicate dbs.|
|Previous:||From: John A Meinel||Date: 2005-05-25 00:38:08|
|Subject: Re: Select performance vs. mssql|