Re: SELECT AND AGG huge tables

From: Ants Aasma <ants(at)cybertec(dot)at>
To: houmanb <houman(at)gmx(dot)at>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: SELECT AND AGG huge tables
Date: 2012-10-19 12:24:46
Message-ID: CA+CSw_uHEriZmX-ye31+HZfAR56hoH4qS5TC2U8UGAEY_PXwMA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Oct 17, 2012 at 2:24 PM, houmanb <houman(at)gmx(dot)at> wrote:
> Hi all,
> Thanks for your advice and the link about posting my question in an
> appropriate form.
> Here are the info. I thank all of you in advance.

Can you run the EXPLAIN once more with EXPLAIN (ANALYZE, BUFFERS,
TIMING OFF). Given the number of rows processed by the query, the
detailed per node timing overhead might be a considerable factor here.

What happened to the "WHERE T.creation_date=$SOME_DATE" part of the
query. These examples go through the whole table. The plans shown are
about as fast as it gets. Summarizing 5GB of data will never be fast.
If you need that information quickly, you'll need to actively maintain
the aggregate values via triggers.

Regards,
Ants Aasma
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt
Web: http://www.postgresql-support.de

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2012-10-19 14:20:56 Re: Recursive query gets slower when adding an index
Previous Message Thomas Kellerer 2012-10-19 10:47:08 Recursive query gets slower when adding an index