Re: four minor proposals for 9.5
От | Pavel Stehule |
---|---|
Тема | Re: four minor proposals for 9.5 |
Дата | |
Msg-id | CAFj8pRBPdh0jSXm7scUd03xncgf2uX1BAENpwOYZC3hxhrtp_g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: four minor proposals for 9.5 (Mark Kirkwood <mark.kirkwood@catalyst.net.nz>) |
Список | 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: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
Pavel
Regards
Mark
В списке pgsql-hackers по дате отправления: