| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: About limit on cube dimensions |
| Date: | 2014-08-31 22:10:37 |
| Message-ID: | 19659.1409523037@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> Shida Sato wrote
>> Why is there limit on the number of cube dimensions?
>> From the docs: http://www.postgresql.org/docs/9.4/static/cube.html
> "To make it harder for people to break things, there is a limit of 100 on
> the number of dimensions of cubes. This is set in cubedata.h if you need
> something bigger."
> Thus the limit is indeed arbitrary - though if you decide to recompile to
> increase that limit your expectations should be sufficient tempered since
> likely few (if any) people are using cubes with 100 times the default limit
> number of dimensions.
Just offhand, it seems like that limit is doing a couple of things:
* Protecting against overflow in memory allocation requests. In theory
we could raise the limit to something near MaxAllocSize/(sizeof(double)*2)
without breaking this.
* Protecting against locking up the server if there are slow (O(N^2) or
worse) algorithms in any of the cube functions.
Before considering a proposal to raise the default value I'd want to see
some investigation of the second point.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2014-08-31 22:38:49 | Re: About limit on cube dimensions |
| Previous Message | David G Johnston | 2014-08-31 21:58:39 | Re: About limit on cube dimensions |