Bradley Baetz <[EMAIL PROTECTED]> writes:
> By cached, do you mean PREPARE stuff, or something else?
PREPARE, and cached plans in plpgsql, and cached plans in SPI, and
cached plans for foreign keys (though probably those never use IN)
and perhaps other places I'm not thinking of at the moment.
>
On Sun, Jan 26, 2003 at 11:18:31PM -0500, Tom Lane wrote:
> Bradley Baetz <[EMAIL PROTECTED]> writes:
> > Right, or skip it entirely when selecting stuff with unique constraints.
>
> I'm hesitant to do that until we have some scheme in place for
> invalidating cached plans.
By cached, do you mean
Bradley Baetz <[EMAIL PROTECTED]> writes:
> On Sun, Jan 26, 2003 at 09:43:18PM -0500, Tom Lane wrote:
>> We're already checking that as a separate plan alternative. The
>> implementation could be improved a little, though --- we could combine
>> the uniq-ification into the Hash node.
> Right, or
On Sun, Jan 26, 2003 at 09:43:18PM -0500, Tom Lane wrote:
> We're already checking that as a separate plan alternative. The
> implementation could be improved a little, though --- we could combine
> the uniq-ification into the Hash node.
Right, or skip it entirely when selecting stuff with uniqu
Bradley Baetz <[EMAIL PROTECTED]> writes:
> On Sun, Jan 26, 2003 at 06:51:18PM -0500, Tom Lane wrote:
>> But the DISTINCT case is a different query. The question that's really
>> at hand is why does the planner mistakenly prefer merge to hash join in
>> the non-DISTINCT case.
> Well, its a differ
On Sun, Jan 26, 2003 at 06:51:18PM -0500, Tom Lane wrote:
> Bradley Baetz <[EMAIL PROTECTED]> writes:
> > On Sun, Jan 26, 2003 at 02:09:49PM -0500, Tom Lane wrote:
> >> This isn't really anything to do with the new IN code, but is a
> >> long-standing problem: cost_mergejoin doesn't apply any penal
Bradley Baetz <[EMAIL PROTECTED]> writes:
> On Sun, Jan 26, 2003 at 02:09:49PM -0500, Tom Lane wrote:
>> This isn't really anything to do with the new IN code, but is a
>> long-standing problem: cost_mergejoin doesn't apply any penalty factor
> Hmm. I'm not sure that that is the entire story. For
On Sun, Jan 26, 2003 at 02:09:49PM -0500, Tom Lane wrote:
>
> This isn't really anything to do with the new IN code, but is a
> long-standing problem: cost_mergejoin doesn't apply any penalty factor
> for the case where there are lots of duplicates in both inner and outer
> relation (causing resca
Bradley Baetz <[EMAIL PROTECTED]> writes:
> I've been trying out the new hased subselect code from CVS. It appears
> that the planner isn't taking the distinctiveness of the values from the
> subselect into account:
This isn't really anything to do with the new IN code, but is a
long-standing prob
I've been trying out the new hased subselect code from CVS. It appears
that the planner isn't taking the distinctiveness of the values from the
subselect into account:
bbaetz=# explain analyze select count(*) FROM bugs where product_id IN
(SELECT product_id FROM bugs);
QUERY PLAN
---
10 matches
Mail list logo
