> Neil Conway wrote:
> There is no such thing as "PG 8.3".
I meant 8.1.3
> please provide the queries that trigger the problem and the
> relevant schema definitions.
Sorry about not posting more details initially. I was running out the
door and was hasty.
> Try re-running ANALYZE and retryi
Neil Conway <[EMAIL PROTECTED]> writes:
>> -> Index Scan Backward using merged_weight_date_idx on merged
>> (cost=0.00..31295593.98 rows=141839 width=229) (actual
>> time=3.888..10380.783 rows=500 loops=1)
> The mis-estimation of the result set of the index scan is clearly a
> problem -- have
On Tue, 2006-03-21 at 16:58 -0500, Kevin Murphy wrote:
> I have a table for which PG 8.3 is guessing wrong about a plan when the
> result set gets large.
There is no such thing as "PG 8.3".
>-> Index Scan Backward using merged_weight_date_idx on merged
> (cost=0.00..31295593.98 rows=14183
I have a table for which PG 8.3 is guessing wrong about a plan when the
result set gets large. For these large result sets, it uses an Index
Scan Backward/Filter (slower) instead of Sort/Bitmap Heap Scan/Bitmap
Index Scan (faster). See below.
I fooled around with various planner variables, b
