From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rick Otten <rottenwindfish(at)gmail(dot)com> |
Cc: | "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: max partitions behind a view? |
Date: | 2017-09-18 13:55:08 |
Message-ID: | 9918.1505742908@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Rick Otten <rottenwindfish(at)gmail(dot)com> writes:
> The challenge is that because of an exponential rate of data growth, I
> might have to significantly increase the number of partitions I'm working
> with - to several hundred at a minimum and potentially more than 1000...
> This leads me to the question how many 'union all' statements can I have in
> one view?
I don't think there's a hard limit short of INT32_MAX or so, but I'd be
worried about whether there are any O(N^2) algorithms that would start
to be noticeable at the O(1000) level.
> Should I create a hierarchy of views to gradually roll the data
> up instead of putting them all in one top-level view?
That would likely make things worse not better; the planner would flatten
them anyway and would expend extra cycles doing so. You could perhaps
stop the flattening with optimization fences (OFFSET 0) but I really doubt
you want the side-effects of that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neto pr | 2017-09-18 14:31:47 | Re: Pageinspect bt_metap help |
Previous Message | Rick Otten | 2017-09-18 11:25:14 | max partitions behind a view? |