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
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 |