| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | depesz(at)depesz(dot)com |
| Cc: | Lefteris <lsidir(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Air-traffic benchmark |
| Date: | 2010-01-08 00:38:34 |
| Message-ID: | 4B467E8A.5000207@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
hubert depesz lubaczewski wrote:
> Well, this query basically has to be slow. Correct approach to this
> problem is to add precalculated aggregates...
The point of this data set and associated queries is to see how fast the
database can do certain types of queries on its own. Some other types
of database implementations automatically do well here due to column
storage and other techniques; the idea is to measure how you can do
without trying to rewrite the app any though. If precomputed aggregates
were added, they'd improve performance for everybody else, too.
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Marlowe | 2010-01-08 01:40:14 | Re: Massive table (500M rows) update nightmare |
| Previous Message | Kevin Grittner | 2010-01-08 00:18:11 | Re: Massive table (500M rows) update nightmare |