Reviving a thread from two months ago...Francisco asked about a query
that was much slower in 8.3 at
http://archives.postgresql.org/message-id/cone.1288183283.263738.5695.1...@shelca
There was some theorizing about a stats problem. I've now pulled
pg_stats data from the production server, and
Robert Haas writes:
This part looks really strange to me. Here we have a nested loop
whose outer side is estimated to produce 33 rows and whose outer side
is estimated to produce 2 rows.
We have retained someone to help us troubleshoot the issue.
Once the issue has been resolved I will make s
On Wed, Oct 27, 2010 at 8:41 AM, Francisco Reyes wrote:
> -> Nested Loop (cost=293.80..719.87
> rows=2434522 width=4) (actual time=228.867..241.909 rows=2 loops=1)
> -> HashAggregate (cost=293.80..294.13
> rows=33 width=29) (a
Hello
>
> The 8.4 machines have more memory than the 8.3.7 and are in general much
> better machines.
> 8.4 settings
> Shared_buffers 18GB
> effective_cache_size 18GB
>
> Machines have 72GB of RAM
> Tried turning off sequential scan on the 8.4.5 and that did not help.
>
> Any ideas/suggestions?
>
CentOS 5.4 and 5.5
Query
SELECT sum(usramt) as givensum,
sum (case when usedid > 0 then usramt else 0 end) as usedsum
FROM argrades
WHERE userstatus in (5) and
membid in (select distinct members.membid from members, cards
where members.membid =
