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:



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 по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: four minor proposals for 9.5
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: Review: plpgsql.extra_warnings, plpgsql.extra_errors