Skip site navigation (1) Skip section navigation (2)

Re: Performance issue with 8.2.3 - "C" application

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karl Denninger <karl(at)denninger(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance issue with 8.2.3 - "C" application
Date: 2007-07-25 02:45:58
Message-ID: 29633.1185331558@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
Karl Denninger <karl(at)denninger(dot)net> writes:
> But.... here's the query that has a habit of taking the most time....

> select forum, * from post where toppost = 1 and (replied > (select 
> lastview from forumlog where login='theuser' and forum=post.forum and 
> number is null)) is not false AND (replied > (select lastview from 
> forumlog where login='theuser' and forum=post.forum and 
> number=post.number)) is not f
> alse order by pinned desc, replied desc offset 0 limit 20

Did that ever perform well for you?  It's the sub-selects that are
likely to hurt ... in particular,

>          ->  Index Scan using post_top on post  (cost=0.00..57266.37 
> rows=113 width=757)
>                Index Cond: (toppost = 1)
>                Filter: (((replied > (subplan)) IS NOT FALSE) AND 
> ((replied > (subplan)) IS NOT FALSE))

versus

>  Index Scan using post_top on post  (cost=0.00..632.03 rows=1013 width=11)
>    Index Cond: (toppost = 1)

The planner thinks that the two subplan filter conditions will eliminate
about 90% of the rows returned by the bare indexscan (IIRC this is
purely a rule of thumb, not based on any statistics) and that testing
them 1013 times will add over 50000 cost units to the basic indexscan.
That part I believe --- correlated subqueries are expensive.

			regards, tom lane

In response to

Responses

pgsql-performance by date

Next:From: Karl DenningerDate: 2007-07-25 02:55:45
Subject: Re: Performance issue with 8.2.3 - "C" application
Previous:From: Merlin MoncureDate: 2007-07-25 01:28:00
Subject: Re: [PERFORM] 8.2 -> 8.3 performance numbers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group