From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Omar Bettin <o(dot)bettin(at)informaticaindustriale(dot)it> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [9.1] unusable for large views |
Date: | 2011-10-24 13:54:02 |
Message-ID: | CA+Tgmoay_H9s_rVuoT4WjLNG=hfiWR8QgKh1GKjiv-X0G4ax_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 24, 2011 at 4:57 AM, Omar Bettin
<o(dot)bettin(at)informaticaindustriale(dot)it> wrote:
> I have tried 9.1.1 win64 version and when I am trying to declare a cursor
> for a very large view (lot of joins and aggregate functions),
>
> postgres is using around 3GB of memory and the query never returns.
Hmm. A 59-table join is pretty enormous.
I wish we had a better way to handle these kinds of queries. Odds are
good that the join order doesn't matter much, and in an ideal world we
would be able to notice that and just use some simple heuristic to
pick a tolerably good one. As it is, I am a bit surprised to hear
that GEQO isn't bailing you out.
Can you EXPLAIN a query against that view, or does even that wipe out?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-10-24 13:57:06 | Re: autovacuum and orphaned large objects |
Previous Message | Robert Haas | 2011-10-24 13:48:40 | Re: termination of backend waiting for sync rep generates a junk log message |