Re: Optimizing a huge_table/tiny_table join - Mailing list pgsql-performance

From Tom Lane
Subject Re: Optimizing a huge_table/tiny_table join
Date
Msg-id 7082.1148521319@sss.pgh.pa.us
Whole thread Raw
In response to Optimizing a huge_table/tiny_table join  (<kynn@panix.com>)
Responses Re: Optimizing a huge_table/tiny_table join
Re: Optimizing a huge_table/tiny_table join
List pgsql-performance
<kynn@panix.com> writes:
>  Limit  (cost=19676.75..21327.99 rows=6000 width=84)
>    ->  Hash Join  (cost=19676.75..1062244.81 rows=3788315 width=84)
>          Hash Cond: (upper(("outer".id)::text) = upper(("inner".id)::text))
>          ->  Seq Scan on huge_table h  (cost=0.00..51292.43 rows=2525543 width=46)
>          ->  Hash  (cost=19676.00..19676.00 rows=300 width=38)
>                ->  Seq Scan on tiny_table t  (cost=0.00..19676.00 rows=300 width=38)

Um, if huge_table is so much bigger than tiny_table, why are the cost
estimates for seqscanning them only about 2.5x different?  There's
something wacko about your statistics, methinks.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Optimizing a huge_table/tiny_table join
Next
From: "Ian Westmacott"
Date:
Subject: Re: Getting even more insert performance (250m+rows/day)