From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Odd out of memory problem. |
Date: | 2012-03-26 16:11:25 |
Message-ID: | 10133.1332778285@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 03/26/2012 11:18 AM, Tom Lane wrote:
>> Could we see EXPLAIN output for this query?
> Currently it shows:
> Limit (cost=19443025.87..19443025.89 rows=10 width=8
> -> Sort (cost=19443025.87..19446451.29 rows=1370168 width=8)
> Sort Key: (max(pageno))
> -> GroupAggregate (cost=18537785.99..19413417.03 rows=1370168
> width=8)
> -> Sort (cost=18537785.99..18823953.97 rows=114467192
> width=8)
> Sort Key: loid
> -> Seq Scan on ldata (cost=0.00..1651163.92
> rows=114467192 width=8)
> The table might have been analysed since I ran the query, though.
That plan should not create a tuple hash table, so I think it's almost
certain that the plan changed. It might be interesting to remove the
pg_statistic rows for the table and then see what plan you get.
> To answer Hans' question, we have seen the problem in other contexts. We
> first noticed this problem in a failure to restore large objects when
> running pg_restore.
[ scratches head... ] I don't understand how or why pg_restore would be
executing such a query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2012-03-26 16:20:51 | Re: Odd out of memory problem. |
Previous Message | Andrew Dunstan | 2012-03-26 15:48:18 | Re: Odd out of memory problem. |