I wrote:
> I chewed on this for awhile and decided that there'd be no real harm in
> taking identification of the unique expressions out of
> create_unique_path() and doing it earlier, in initsplan.c; we'd need a
> couple more fields in SpecialJoinInfo but that doesn't seem like a
> problem. Howe
=?UTF-8?Q?David_Kube=C4=8Dka?= writes:
> There is division by loop_count because of predicted effect of caching and
> it is exactly this division which makes the run_cost for single index
> lookup so low compared with the query version with random_fk_uniq. So the
> main problem is that the planne
On 3/5/15 7:58 PM, Jim Nasby wrote:
This got answered on one of the other lists, right?
That was supposed to be off-list. I'll answer my own question: yes.
Sorry for the noise. :(
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
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
ro
Hi Tomas and others,
2015-03-02 21:29 GMT+01:00 Tomas Vondra :
> Hi David ;-)
>
> On 2.3.2015 20:19, David Kubečka wrote:
> >
> > The question is why optimizer, or rather the cost estimator,
> > produced so much different estimates upon very small change in input.
> > Moreover it seems that the m
On Mon, Mar 2, 2015 at 2:19 PM, David Kubečka wrote:
> The question is why optimizer, or rather the cost estimator, produced so
> much different estimates upon very small change in input. Moreover it seems
> that the main culprit of bad estimates isn't actually directly related to
> outer table, b
David Kubečka wrote:
> 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
It could be as simple as no
Hi David ;-)
On 2.3.2015 20:19, David Kubečka wrote:
>
> The question is why optimizer, or rather the cost estimator,
> produced so much different estimates upon very small change in input.
> Moreover it seems that the main culprit of bad estimates isn't
> actually directly related to outer table,
