"Erik Aronesty" <[EMAIL PROTECTED]> writes:
> Should I start looking to figure out why the optimizer didn't figure out
> that it should be doing this sort of thing?
It looks to me that the problem is that convert_IN_to_join() is not
being smart about where to attach the IN's subselect to the join
In my database, the "sites" table is large, and the "usersites" table
has only a few sites per userid - so it should be looked in first. I'm
surprised that I had to juggle my query around (below), rather than
trusting the optimizer to figure this out for me.
Should I start looking to figure out w
On 6/17/05, Marc G. Fournier <[EMAIL PROTECTED]> wrote:
> On Fri, 17 Jun 2005, Tom Lane wrote:
>
> > "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Does that make sense? Would it ever get used?
> >
> > It could get used if one of the two values is far less frequent than the
> > other. Perso
On Fri, 17 Jun 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Does that make sense? Would it ever get used?
It could get used if one of the two values is far less frequent than the
other. Personally I'd think about a partial index instead ...
Hr, hadn't thought o
how about an very large table with a "processed" type flag?
uru
-Dave
Marc G. Fournier wrote:
Does that make sense? Would it ever get used? I can't see it, but
figured I'd ask ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Does that make sense? Would it ever get used?
It could get used if one of the two values is far less frequent than the
other. Personally I'd think about a partial index instead ...
regards, tom lane
--
Does that make sense? Would it ever get used? I can't see it, but
figured I'd ask ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(end of broadcast)-
