Re: PG's suitability for high volume environment (many INSERTs and lots of aggregation reporting)
В списке pgsql-general по дате отправления:
| От | Gregory Stark |
|---|---|
| Тема | Re: PG's suitability for high volume environment (many INSERTs and lots of aggregation reporting) |
| Дата | |
| Msg-id | 871vunldcu.fsf@oxford.xeocode.com обсуждение исходный текст |
| Ответ на | PG's suitability for high volume environment (many INSERTs and lots of aggregation reporting) (Phoenix Kiula <phoenix.kiula@gmail.com>) |
| Список | pgsql-general |
Phoenix Kiula <phoenix.kiula@gmail.com> writes: > My question: with that kind of volume and the underlying aggregation > functions (by product id, dates, possibly IP addresses or at least > countries of origin..) will PG ever be a good choice? Well, only you're able to judge that for your own data and use cases. Your query is sorting 10,000 records in half a second which is not great but not terrible either. I think the only way you'll be able to speed that up is by changing your index design so that Postgres can access the data you need without sorting through all the irrelevant records. I suspect others already suggested this, but you might look at partial indexes. If your queries are very dynamic against relatively static data you might look at building denormalized caches of the precalculated data. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера