Re: [PERFORM] how to help the planner

2013-03-28 Thread Stephen Frost
Marty, * Marty Frasier (m.fras...@escmatrix.com) wrote: > We have a particular query that takes about 75 minutes to complete. The > selected execution plan estimates 1 row from several of the outermost > results so picks nested loop join resolutions. That turns out to be a bad > choice since act

Re: [PERFORM] Question about postmaster's CPU usage

2013-03-28 Thread k...@rice.edu
On Thu, Mar 28, 2013 at 02:03:42PM -0700, Kevin Grittner wrote: > kelphet xiong wrote: > > > When I use postgres and issue a simple sequential scan for a > > table inventory using query "select * from inventory;", I can see > > from "top" that postmaster is using 100% CPU, which limits the > > qu

Re: [PERFORM] Question about postmaster's CPU usage

2013-03-28 Thread Kevin Grittner
kelphet xiong wrote: > When I use postgres and issue a simple sequential scan for a > table inventory using query "select * from inventory;", I can see > from "top" that postmaster is using 100% CPU, which limits the > query execution time. My question is that, why CPU is the > bottleneck here an

Re: [PERFORM] how to help the planner

2013-03-28 Thread Marty Frasier
Tom, I cranked (join|from)_collapse_limit up to 50, then 500 just to exclude the limits completey, and attempted the query both times. The planner came up with an estimate close to the other estimates (1,944,276) and I stopped actual execution after some length of time. The t12 subquery is group

[PERFORM] Question about postmaster's CPU usage

2013-03-28 Thread kelphet xiong
Hi all, When I use postgres and issue a simple sequential scan for a table inventory using query "select * from inventory;", I can see from "top" that postmaster is using 100% CPU, which limits the query execution time. My question is that, why CPU is the bottleneck here and what is postmaster

Re: [PERFORM] how to help the planner

2013-03-28 Thread Tom Lane
Marty Frasier writes: > We've been using postgreSQL for a few years. This is my first post here > and first real dive into query plans. One quick thought is that it's probably worth cranking up join_collapse_limit and/or from_collapse_limit, since the number of relations in the query is consider

[PERFORM] how to help the planner

2013-03-28 Thread Marty Frasier
Greetings, We've been using postgreSQL for a few years. This is my first post here and first real dive into query plans. A description of what you are trying to achieve and what results you expect.: Query results of nested joins of table. Results are correct - just takes a long time with sel