Re: Too many range table entries error

From: Andres Freund <andres(at)anarazel(dot)de>
To: Akshaya Acharya <akshaya(dot)acharya(dot)01(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Too many range table entries error
Date: 2018-06-25 18:14:10
Message-ID: 20180625181410.fg5xejq4qsbnryl2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2018-06-25 13:46:06 +0530, Akshaya Acharya wrote:
> On Mon, 25 Jun 2018 at 13:40, Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > Hi,
> >
> > On 2018-06-25 13:02:37 +0530, Akshaya Acharya wrote:
> > > Hello.
> > >
> > >
> > > Please could you help debug the error "too many range table entries”?
> > >
> > >
> > > This error occurs when querying a view that is dependent on many other
> > > views (i.e. a view high up in the pyramid of views that we've
> > constructed).
> > >
> > >
> > > I get this error when running select * on the view, or when running an
> > > explain analyse on the select.
> > >
> > >
> > > Views that use a total of more than around 40000 table references (in the
> > > complete tree considering all the dependent views recursively) don't
> > work,
> > > but it works with 20000 table references. What is the maximum number of
> > > table references possible?
> >
> > Why are you doing this? I can't imagine queries with that many table
> > references ever being something useful? I'm pretty sure there's better
> > solutions for what you're doing.
> >
>
> Our entire application—all our business logic—is built as layers of views
> inside the database. The ref counts sort of multiple at each layer, hence
> the large number.

That still doesn't explain how you realistically get to 40k references,
and how that's a reasonable design. There's be quite the massive runtime
and memory overhead for an approach like this. What was the reasoning
leading to this architecture.

> > > Can I increase this number somehow?
> >
> > It's not impossible, it's not entirely trivial either. The relevant
> > variables currently are 16bit wide, and the limit is close to the max
> > for that.
> >
>
> I understand.
>
> At slide 25 of this presentation a patch is indicated. Is this relevant to
> our situation?
> https://www.slideshare.net/hansjurgenschonig/postgresql-joining-1-million-tables

Yes, but that change likely isn't sufficient.

> Alternatively we will have to optimize our views or change the architecture
> of our application? Is there any other way to resolve this situation?

Yes I think you will have to, and no I don't see any other.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2018-06-25 18:52:36 Re: Schema/Data conversion opensource tools from MySQL to PostgreSQL
Previous Message Vikas Sharma 2018-06-25 17:21:51 DB size growing exponentially when materialized view refreshed concurrently (postgres 9.6)