Re: Query runs very slowly in Postgres, but very fast in other DBMS

From: Krasimir Dimitrov <kr(at)aiidatapro(dot)com>
To: "Andrus Moor" <eetasoft(at)online(dot)ee>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Query runs very slowly in Postgres, but very fast in other DBMS
Date: 2005-04-12 06:33:16
Message-ID: 200504120933.17457.kr@aiidatapro.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql


try this query :

SELECT rid.dokumnr as d1 ,dok.dokumnr as d2 FROM rid left join dok on
rid.dokumnr = dok.dokumnr where dok.dokumnr is null;

> Tables:
>
> CREATE TABLE dok ( dokumnr NUMERIC(12),
> CONSTRAINT dok_pkey PRIMARY KEY (dokumnr) );
> CREATE TABLE rid ( dokumnr NUMERIC(12) );
> CREATE INDEX rid_dokumnr_idx ON rid (dokumnr);
>
> Query:
>
> SELECT dokumnr FROM rid WHERE dokumnr NOT IN
> (select dokumnr FROM dok);
>
> runs VERY slowly in Postgres. It uses the following query plan:
>
> Seq Scan on rid (cost=0.00..28698461.07 rows=32201 width=14)
> Filter: (NOT (subplan))
> SubPlan
> -> Seq Scan on dok (cost=0.00..864.29 rows=10729 width=14)
>
> In Microsoft Visual FoxPro this query runs fast. FoxPro uses indexes speed
> up the query by comparing bitmaps.
>
> Is it possible to speed up this query is Postgres ? How to force Postgres
> to use indexes for this query ?
>
> Andrus
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)

--
________________________________________________________
Krasimir Dimitrov
IT Department
AII Data Processing Ltd.,
16 Ivan Vazov Str,
Sofia 1000,
Bulgaria
Phone: +359 2 9376 352
E-mail: kr(at)aiidatapro(dot)com
http://www.see-news.com

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Richard Huxton 2005-04-12 07:30:40 Re: Update aborted if trigger function fails?
Previous Message Tom Lane 2005-04-12 05:43:10 Re: Query runs very slowly in Postgres, but very fast in other DBMS