Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
Facebook
Downloads
Home
>
mailing lists
Hash Aggregate plan picked for very large table == out of memory - Mailing list pgsql-general
From
Mason Hale
Subject
Hash Aggregate plan picked for very large table == out of memory
Date
June 14, 2007
20:15:17
Msg-id
8bca3aa10706141315k38d89d74occ317907f68ed54d@mail.gmail.com
Whole thread
Raw
Responses
Re: Hash Aggregate plan picked for very large table == out of memory
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Hash Aggregate plan picked for very large table == out of memory
(Gregory Stark <stark@enterprisedb.com>)
List
pgsql-general
Tree view
With Postgresql 8.1.9 -- I have a simple group by query:
SELECT target_page_id, min(created_at)
FROM page_page_link
GROUP BY 1;
The page_page_link table has ~130 million rows.
After analyzing the table, the planner picks a hash aggregate plan, which results in an out of memory error.
crystal=> analyze page_page_link;
ANALYZE
crystal=> explain
crystal-> SELECT target_page_id as page_id, min(created_at) as created_at
crystal-> FROM page_page_link
crystal-> GROUP By 1
crystal-> ;
QUERY PLAN
-----------------------------------------------------------------------------------
HashAggregate (cost=3663517.88..3670393.09 rows=550017 width=12)
-> Seq Scan on page_page_link (cost=0.00..2993649.92 rows=133973592 width=12)
(2 rows)
The default_statistics_target was originally 200.
I upped it to 1000 and still get the same results.
crystal=> show default_statistics_target;
default_statistics_target
---------------------------
1000
(1 row)
crystal=> set enable_hashagg = off;
SET
crystal=> explain
crystal-> SELECT target_page_id as page_id, min(created_at) as created_at
crystal-> FROM page_page_link
crystal-> GROUP BY 1
crystal-> ;
QUERY PLAN
-----------------------------------------------------------------------------------------
GroupAggregate (cost=27240841.37..28252518.53 rows=550017 width=12)
-> Sort (cost=27240841.37..27575775.35 rows=133973592 width=12)
Sort Key: target_page_id
-> Seq Scan on page_page_link (cost= 0.00..2993649.92 rows=133973592 width=12)
(4 rows)
crystal=>
I am working around this by setting enable_hashagg = off -- but it just seems like a case where the planner is not picking the strategy?
Is there another setting I can change to help make better decisions?
thanks in advance,
Mason
pgsql-general
by date:
Previous
From:
"Shoaib Mir"
Date:
14 June 2007, 20:06:54
Subject:
Re: Function with COPY command?
Next
From:
Francisco Reyes
Date:
14 June 2007, 20:18:10
Subject:
pg_restore out of memory
Есть вопросы? Напишите нам!
Соглашаюсь с условиями обработки персональных данных
I confirm that I have read and accepted PostgresPro’s
Privacy Policy
.
I agree to get Postgres Pro discount offers and other marketing communications.
✖
×
×
Everywhere
Documentation
Mailing list
List:
all lists
pgsql-general
pgsql-hackers
buildfarm-members
pgadmin-hackers
pgadmin-support
pgsql-admin
pgsql-advocacy
pgsql-announce
pgsql-benchmarks
pgsql-bugs
pgsql-chat
pgsql-cluster-hackers
pgsql-committers
pgsql-cygwin
pgsql-docs
pgsql-hackers-pitr
pgsql-hackers-win32
pgsql-interfaces
pgsql-jdbc
pgsql-jobs
pgsql-novice
pgsql-odbc
pgsql-patches
pgsql-performance
pgsql-php
pgsql-pkg-debian
pgsql-pkg-yum
pgsql-ports
pgsql-rrreviewers
pgsql-ru-general
pgsql-sql
pgsql-students
pgsql-testers
pgsql-translators
pgsql-www
psycopg
Period
anytime
within last day
within last week
within last month
within last 6 months
within last year
Sort by
date
reverse date
rank
Services
24×7×365 Technical Support
Migration to PostgreSQL
High Availability Deployment
Database Audit
Remote DBA for PostgreSQL
Products
Postgres Pro Enterprise
Postgres Pro Standard
Cloud Solutions
Postgres Extensions
Resources
Blog
Documentation
Webinars
Videos
Presentations
Community
Events
Training Courses
Books
Demo Database
Mailing List Archives
About
Leadership team
Partners
Customers
In the News
Press Releases
Press Info
By continuing to browse this website, you agree to the use of cookies. Go to
Privacy Policy
.
I accept cookies