Tom Lane wrote:
Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
I guess is too late for 7.3.5.
:-(
Any chance for 7.4.1 ?
Regards
Gaetano Mendola
---(end of broadcast)---
TIP 3: if posting/re
Greg Stark wrote:
Jared Carr <[EMAIL PROTECTED]> writes:
The patch definitely makes things more consistent...unfortunately it is more
consistent toward the slower execution times. Of course I am looking at this
simply from a straight performance standpoint and not a viewpoint of what
*should*
Tom Lane wrote:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> Define "no longer works well".
>
> > Well it seems to completely bar the use of a straight merge join between two
> > index scans:
>
> Hmmm ... [squints] ... it's not supposed to do that ... [di
Jared Carr <[EMAIL PROTECTED]> writes:
> The patch definitely makes things more consistent...unfortunately it is more
> consistent toward the slower execution times. Of course I am looking at this
> simply from a straight performance standpoint and not a viewpoint of what
> *should* be happening.
Tom Lane wrote:
Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
The patch definitely makes things more consistent...unfortunately it is
more
consistent toward the slower execution times. Of course I am looking at
this
simply from a st
> Hmmm ... [squints] ... it's not supposed to do that ...
The attached patch seems to make it better.
regards, tom lane
Index: src/backend/optimizer/path/costsize.c
===
RCS file: /cvsroot/pgsql-server/src/ba
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Define "no longer works well".
> Well it seems to completely bar the use of a straight merge join between two
> index scans:
Hmmm ... [squints] ... it's not supposed to do that ... [digs] ... yeah,
there's something
Tom Lane <[EMAIL PROTECTED]> writes:
> Define "no longer works well". varchar doesn't have its own comparison
> operators anymore, but AFAIK that makes no difference.
Well it seems to completely bar the use of a straight merge join between two
index scans:
test=# set enable_seqscan = off;
SET
Greg Stark <[EMAIL PROTECTED]> writes:
> Huh. The following shows something strange. It seems joining on two varchars
> no longer works well. Instead the optimizer has to convert both columns to
> text.
Define "no longer works well". varchar doesn't have its own comparison
operators anymore, but
Greg Stark <[EMAIL PROTECTED]> writes:
> Huh. The following shows something strange.
Worse, with enable_hashjoin off it's even more obvious something's broken:
test=# set enable_hashjoin = off;
SET
test=# explain select * from a,b where a.x=b.x;
QUERY PLAN
Jared Carr <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>
> > Well it looks like you have something strange going on. What data type is
> > car_id in each table?
> >
> car_id is a varchar(10) in both tables.
Huh. The following shows something strange. It seems joining on two varchars
no long
Greg Stark wrote:
Jared Carr <[EMAIL PROTECTED]> writes:
Greg Stark wrote:
Merge Cond: ("outer"."?column7?" = "inner"."?column5?")
Well it looks like you have something strange going on. What data type is
car_id in each table?
car_id is a varchar(10) in both table
Jared Carr <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>
> >
> >> Merge Cond: ("outer"."?column7?" = "inner"."?column5?")
> >>
> >
> >Well it looks like you have something strange going on. What data type is
> > car_id in each table?
> car_id is a varchar(10) in both tables.
Well for
Greg Stark wrote:
Merge Cond: ("outer"."?column7?" = "inner"."?column5?")
Well it looks like you have something strange going on. What data type is
car_id in each table?
car_id is a varchar(10) in both tables.
---(end of broadcast)---
Jared Carr <[EMAIL PROTECTED]> writes:
> Furthermore noticed that in the following query plan it is doing the
> sequential scan on quotes first, and then doing the sequential on zips. IMHO
> this should be the other way around, since the result set for zips is
> considerably smaller especially giv
Robert Treat wrote:
On Mon, 2003-12-01 at 16:44, Jared Carr wrote:
I am currently working on optimizing some fairly time consuming queries
on a decently large
dataset.
The Following is the query in question.
SELECT z.lat, z.lon, z.city, z.state, q.date_time, c.make, c.model, c.year
FROM q
On Mon, 2003-12-01 at 16:44, Jared Carr wrote:
> I am currently working on optimizing some fairly time consuming queries
> on a decently large
> dataset.
>
> The Following is the query in question.
>
> SELECT z.lat, z.lon, z.city, z.state, q.date_time, c.make, c.model, c.year
> FROM quotes A
Jared Carr <[EMAIL PROTECTED]> writes:
> I am currently working on optimizing some fairly time consuming queries
> on a decently large dataset.
It doesn't look that large from here ;-). I'd suggest experimenting
with reducing random_page_cost, since at least for your test query
it sure looks lik
I am currently working on optimizing some fairly time consuming queries
on a decently large
dataset.
The Following is the query in question.
SELECT z.lat, z.lon, z.city, z.state, q.date_time, c.make, c.model, c.year
FROM quotes AS q, zips AS z, cars AS c
WHERE
z.zip = q.zip
19 matches
Mail list logo
