From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: four minor proposals for 9.5 |
Date: | 2014-03-20 08:59:33 |
Message-ID: | CAFj8pRBPdh0jSXm7scUd03xncgf2uX1BAENpwOYZC3hxhrtp_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2014-03-20 9:47 GMT+01:00 Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>:
> On 20/03/14 20:08, Pavel Stehule wrote:
>
>>
>>
>>
>> 2014-03-20 7:25 GMT+01:00 Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz
>> Also I think this would probably only make sense for TEMPORARY
>> tables - otherwise you can get this sort of thing going on:
>>
>> - you create a table and you have set a relation size limit
>> - you commit and keep working
>> - I add a whole lot of rows to your new table (taking it over the
>> limit)
>> - you go to add some more rows to this table...
>>
>>
>> you cannot to across session limit and is not important if you do
>> inserts more times or once.
>>
>>
> Sorry Pavel - what you have said above is difficult for me to understand -
> if the limit is intended as a *session* limit then concurrent activity from
> multiple sessions makes it behave - well - strangely to say the least, as
> tables are essentially shared resources.
>
I am sorry, I should to explain first our use case. Our product support
multidimensional modelling - usually we have a few (less than 1000)
unlimited user data tables. When user can to see some view (report), our
engine generate 10 - 100 queries and result of these queries are stored in
tables. Then result of one calculation can be shared between reports,
users. These tables (caches) are semi temporal - life cycle is about hour,
max days. Some queries in multidimensional analysis are Cartesian products
- we are not able to estimate well a sizes of these tables - due free
schema - users can create own logical model (users can fill these data
freely) - and variability of generated queries is too long.
So we need to some safeguards in background.
Regards
Pavel
>
> Regards
>
> Mark
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2014-03-20 11:39:38 | Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors |
Previous Message | Mark Kirkwood | 2014-03-20 08:47:59 | Re: four minor proposals for 9.5 |