Re: four minor proposals for 9.5 - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: four minor proposals for 9.5
Date
Msg-id CAFj8pRBPdh0jSXm7scUd03xncgf2uX1BAENpwOYZC3hxhrtp_g@mail.gmail.com
Whole thread Raw
In response to Re: four minor proposals for 9.5  (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>)
List pgsql-hackers



2014-03-20 9:47 GMT+01:00 Mark Kirkwood <mark.kirkwood@catalyst.net.nz>:
On 20/03/14 20:08, Pavel Stehule wrote:



2014-03-20 7:25 GMT+01:00 Mark Kirkwood <mark.kirkwood@catalyst.net.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


pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: four minor proposals for 9.5
Next
From: Petr Jelinek
Date:
Subject: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors