Re: select count() out of memory

From: Thomas Finneid <tfinneid(at)student(dot)matnat(dot)uio(dot)no>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Thomas Finneid <tfinneid(at)student(dot)matnat(dot)uio(dot)no>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: select count() out of memory
Date: 2007-10-26 06:25:09
Message-ID: 47218845.5020305@ifi.uio.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Gregory Stark wrote:
> Tom's point is that if you have 55k tables then just *finding* the newest
> child table is fairly expensive. You're accessing a not insignificant-sized
> index and table of tables. And the situation is worse when you consider the
> number of columns all those tables have, all the indexes those tables have,
> all the column keys those indexes the tables have have, etc.

Yes, I got that. But I name the child tables so that I when my server
receives read requests, I retreive details from the request to be able
to figure out the exact child table name, without the system needing to
do any internal searches to find the newest table.

> Nonetheless you've more or less convinced me that you're not completely nuts.

thank you for only regarding me as somewhat nuts :)

> I would suggest not bothering with inheritance though. Inheritance imposes
> additional costs to track the inheritance relationships. For your purposes you
> may as well just create separate tables and not bother trying to use
> inheritance.

As addressed in a previous reply, I find inheritance better for a couple
of practical reasons.

>> If its practical to use partitions, granularity does not come into the
>> equation.
>
> Uhm, yes it does. This is engineering, it's all about trade-offs. Having 55k
> tables will have costs and benefits. I think it's a bit early to dismiss the
> costs. Keep in mind that profiling them may be a bit tricky since they occur
> during planning and DDL that you haven't finished experimenting with yet. The
> problem you just ran into is just an example of the kind of costs it imposes.

See answer on why granularity is not relevant for my case.

> You should also consider some form of compromise with separate tables but at a
> lower level of granularity. Perhaps one partition per day instead of one per
> 30s. you could drop a partition when all the keys in it are marked as dead.

The structure of the data is divided in a descrete timeline, so every
predefined x seconds a whole new bunch of data arrives, and all that
belongs in a single partition.

regards

thomas

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Finneid 2007-10-26 06:26:13 Re: select count() out of memory
Previous Message Ow Mun Heng 2007-10-26 06:24:46 Query_time SQL as a function w/o creating a new type