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
Bhuvan A wrote:
> > Long Description PostgreSQL has mechanism for commenting databases.
> > Database comments can by read by obj_description(oid), psql \l+ command
> > use it. Database comments should be global, but they are not, when we do
> > \l+ on one database, and then on other, results will b
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
On Thu, 2003-01-23 at 16:45, [EMAIL PROTECTED] wrote:
> running explain analyze on the code below causes postgres to crash. See below for
>error messages.
Can you provide the schema for the tables involved in the query, please?
A backtrace from the core file created when the backend crashes wou
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
---
Emmanuel Guyot ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
pg_restore blocks
Long Description
I launch pg_restore from my Java programs with the following command :
bash --login -c \"/usr/bin/pg_restore.exe -v -c -F c -d myb
13 matches
Mail list logo
