2014-03-20 9:47 GMT+01:00 Mark Kirkwood <mark.kirkw...@catalyst.net.nz>:
> On 20/03/14 20:08, Pavel Stehule wrote: > >> >> >> >> 2014-03-20 7:25 GMT+01:00 Mark Kirkwood <mark.kirkw...@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 > >
