public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Rick Otten <[email protected]>
Cc: pgsql-performa. <[email protected]>
Subject: Re: max partitions behind a view?
Date: Mon, 18 Sep 2017 09:55:08 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAMAYy4Jd12CyPFeumOd8g2ar_DmgfH4cvuE5rxocsdi=KDpf0A@mail.gmail.com>
References: <CAMAYy4Jd12CyPFeumOd8g2ar_DmgfH4cvuE5rxocsdi=KDpf0A@mail.gmail.com>
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgsql-performance>

Rick Otten <[email protected]> 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


-- 
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: max partitions behind a view?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox