From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> |
Cc: | strk(at)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org, postgis-devel(at)postgis(dot)refractions(dot)net |
Subject: | Re: join selectivity |
Date: | 2004-12-16 15:54:30 |
Message-ID: | 24929.1103212470@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mark Cave-Ayland" <m(dot)cave-ayland(at)webbased(dot)co(dot)uk> writes:
> ...and with two indices RESTRICT is called four times. The part I find
> confusing is why with one index that RESTRICT is called twice.
[ shrug... ] clause_selectivity doesn't try to cache the result.
> I was also thinking whether calling RESTRICT when comparing with an unknown
> value is worth doing at all, however I did think that perhaps if you are
> using a cast to perform an operation on two datatypes, then you may be able
> to imply something from the index, such as its physical size, and hint that
> the planner should use a particular index in preference for the other.
That would be inappropriate; the index size is factored in elsewhere
(gistcostestimate() to be specific). Restriction selectivity shouldn't
directly consider the existence of indexes at all.
> Would it be correct to assume that if returning the same value for
> RESTRICT for both means that the planner will choose one at random?
If the tables/indexes are exactly the same size then you'd get the same
cost and the choice would be effectively random.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas DAZ SD | 2004-12-16 16:24:30 | Re: [Testperf-general] BufferSync and bgwriter |
Previous Message | Mark Cave-Ayland | 2004-12-16 14:30:26 | Re: join selectivity |