Обсуждение: Optimizer failure on integer column?

Is there a documented problem with optimizing integer key fields
in 7.3.3?

I have two tables.  One was extracted from the other and has
the following four columns.

    mtranmemid   varchar(8),
    mtranseq     integer,
    mtransts     char,
    mtranmemtp   varchar(2)

mtranseq is a unique index on both tables and contains no nulls.

When I try to do an update, it takes several hours.  Here's what
explain says about the query:

explain update missing_ids
set mtransts = a.mtransts,
mtranmemtp = a.mtranmemtp
from memtran as a
where a.mtranmemid = missing_ids.mtranmemid
and a.mtranseq = missing_ids.mtranseq

                                   QUERY PLAN
--------------------------------------------------------------------------------
 Hash Join  (cost=9231.64..58634.93 rows=1 width=48)
   Hash Cond: ("outer".mtranseq = "inner".mtranseq)
   Join Filter: ("outer".mtranmemid = "inner".mtranmemid)
   ->  Seq Scan on memtran a  (cost=0.00..22282.57 rows=714157 width=26)
   ->  Hash  (cost=6289.91..6289.91 rows=351891 width=22)
         ->  Seq Scan on missing_ids  (cost=0.00..6289.91 rows=351891 width=22)

Incidentally, why can't you define an alias on the primary table in
an update query?  That would make the above a bit easier to write.
--
Mike Nolan

Do you have indexes on the tables?
--
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

nolan@celery.tssi.com writes:
> Is there a documented problem with optimizing integer key fields
> in 7.3.3?

No.  How about providing some more details, like EXPLAIN ANALYZE
output?  The given query plan looks reasonable if the planner's
estimates are right ... but since you're complaining, I'd imagine
they are not.  (Also, I assume you've done an ANALYZE lately?)

            regards, tom lane

Is it an int8 column?  If it is, you have to cast all raw numbers to
int8, or the optimizer won't catch that it can use the index.

For example, in perl

$dbh->prepare("select * from mytable where myinteger = ?::int8");

will be able to use the optimizer.

Jon

On Fri, 6 Jun 2003, Tom Lane wrote:

> nolan@celery.tssi.com writes:
> > Is there a documented problem with optimizing integer key fields
> > in 7.3.3?
>
> No.  How about providing some more details, like EXPLAIN ANALYZE
> output?  The given query plan looks reasonable if the planner's
> estimates are right ... but since you're complaining, I'd imagine
> they are not.  (Also, I assume you've done an ANALYZE lately?)
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>