Re: TPC-R benchmarks

Oleg,

> All right, my query just finished running with EXPLAIN ANALYZE.
> I show the plan below and also attached it as a file.
> Any ideas?

Yes.  Your problem appears to be right here:

>                                        ->  Nested Loop
> (cost=0.00..54596.00 rows=3 width=88) (actual time=482.41..6630601.46
> rows=348760 loops=1)
>                                              Join Filter:
> ("inner".s_suppkey = "outer".l_suppkey)
>                                              ->  Nested Loop
> (cost=0.00..54586.18 rows=3 width=80) (actual time=383.87..6594984.40
> rows=348760 loops=1)
>                                                    ->  Nested Loop
> (cost=0.00..54575.47 rows=4 width=68) (actual time=199.95..3580882.07
> rows=348760 loops=1)
>                                                          Join Filter:
> ("outer".p_partkey = "inner".ps_partkey)
>                                                          ->  Nested Loop
> (cost=0.00..22753.33 rows=9343 width=49) (actual time=146.85..3541433.10
> rows=348760 loops=1)

For some reason, the row estimate on the supplier --> lineitem join is bad, as
is the estimate on part --> partsupp.    Let me first check two things:

1) You have an index on l_suppkey and on ps_partkey.
2) you have run ANALYZE on your whole database before the query

If both of those are true, I'd like to see the lines in pg_stats that apply to
ps_partkey and l_suppkey; please do a:

SELECT * FROM pg_stats WHERE attname = 'l_suppkey' or attname = 'ps_partkey'


--
-Josh Berkus
 Aglio Database Solutions
 San Francisco