Re: Weirdly pesimistic estimates in optimizer - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Weirdly pesimistic estimates in optimizer
Date
Msg-id 54F909A9.8000102@BlueTreble.com
Whole thread Raw
In response to Weirdly pesimistic estimates in optimizer  (David Kubečka <kubecka.dav@gmail.com>)
Responses Re: Weirdly pesimistic estimates in optimizer
List pgsql-hackers
On 2/28/15 12:01 PM, David Kubečka wrote:
> With 'random_fk_dupl':
>           ->  Index Scan using facts_fk_idx on facts  (cost=0.42..5.75
> rows=100 width=15) (actual time=0.009..0.117 rows=98 loops=100)
> With 'random_fk_uniq':
>           ->  Index Scan using facts_fk_idx on facts (cost=0.42..214.26
> rows=100 width=15) (actual time=0.007..0.109 rows=98 loops=100)
>
> I have read the optimizer README file and also looked briefly at the
> code, but this seems to be something not related to particular
> implementation of algorithm (e.g. nested loop). Perhaps it's the way how
> cost estimates are propagated down (or sideways? that would be weird...)
> the query tree. But I am really not sure, since this is my first time
> lookng at the optimizer code base. I should also add that I have
> reproduced this behaviour for all versions of Pg from 9.2 up to current
> devel.

This got answered on one of the other lists, right?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



pgsql-hackers by date:

Previous
From: David G Johnston
Date:
Subject: Re: object description for FDW user mappings
Next
From: Jim Nasby
Date:
Subject: Re: Proposal : REINDEX xxx VERBOSE