Re: Strategy for doing number-crunching

Поиск
Список
Период
Сортировка
Искать
От
Jean-Yves F. Barbier
Тема
Re: Strategy for doing number-crunching
Дата
Msg-id
20120104180824.58ace73f@anubis.defcon1
Ответ на
Список
Дерево обсуждения
Strategy for doing number-crunching Matthew Foster <matthew.foster@noaa.gov>
Re: Strategy for doing number-crunching Tom Lane <tgl@sss.pgh.pa.us>
Re: Strategy for doing number-crunching Matthew Foster <matthew.foster@noaa.gov>
Re: Strategy for doing number-crunching Tom Lane <tgl@sss.pgh.pa.us>
Re: Strategy for doing number-crunching Matthew Foster <matthew.foster@noaa.gov>
Re: Strategy for doing number-crunching "Jean-Yves F. Barbier" <12ukwn@gmail.com>
Re: Strategy for doing number-crunching János Löbb <janos.lobb@yale.edu>
Re: Strategy for doing number-crunching Sean Davis <sdavis2@mail.nih.gov>
Re: Strategy for doing number-crunching "ktm@rice.edu" <ktm@rice.edu>
Re: Strategy for doing number-crunching Sean Davis <sdavis2@mail.nih.gov>
Re: Strategy for doing number-crunching Joe Conway <mail@joeconway.com>
On Wed, 4 Jan 2012 10:36:16 -0600
Matthew Foster  wrote:

Hi Matt,

I'm not a PG guru nor a stats one, so also wait for more skilled
answers:)

You're using a lot of of nested functions that take a lot of CPU, so
IMHO the timing won't be easy to reduce without adding some columns 
that'll "pre-chew" part of the work.

ie: I see enough times "sqrt()" in your query for them to be stored
    in their own column; it'll take a few time at insertion, but will
    save a lot while querying.

An EXPLAIN ANALYSE would also be welcome as there's a big risk that
it shows some calculations are done for *each* row.

About those that can't be pre-calculated, may be calculating+storing
some data first would help (I think about min(), max(), avg()),
depending of what EXPLAIN ANALYSE will show.

JY
-- 
Q:	What's the difference between hard and dark?
A:	It stays dark all night.
В списке pgsql-novice по дате отправления
От: Sean Davis
Дата:
От: Matthew Foster
Дата:
FAQ