Postgres Pro
Downloads
Home   >   mailing lists

Thread: bad join performance

bad join performance

From
pginfo
Date:
Hi ,
I am using pg 7.3.3 on RH 7.3,
dual Athlon
1 GB RAM.

I have 2 tables a_acc and a_vid_doc (all PK are int).

sizes:

 select count(IDS) from a_acc;
  count
---------
 1006772

select count(IDS) from a_vid_doc;
 count
-------
    25

I have problem with the join ot this tables.
I tryed this examples:

 explain analyze select G.IDS  from A_ACC G   join A_VID_DOC VD
ON(G.IDS_VID_DOC=VD.IDS)  WHERE G.IDS = 1338673 ;
                                                               QUERY
PLAN

-----------------------------------------------------------------------------------------------------------------------------------------

 Merge Join  (cost=1.83..1.97 rows=1 width=12) (actual
time=40.78..2085.82 rows=1 loops=1)
   Merge Cond: ("outer".ids_vid_doc = "inner".ids)
   ->  Index Scan using i_a_acc_ids_vid_doc on a_acc g
(cost=0.00..43706.42 rows=1 width=8) (actual time=40.52..2085.55 rows=1
loops=1)
         Filter: (ids = 1338673)
   ->  Sort  (cost=1.83..1.89 rows=25 width=4) (actual time=0.22..0.22
rows=25 loops=1)
         Sort Key: vd.ids
         ->  Seq Scan on a_vid_doc vd  (cost=0.00..1.25 rows=25 width=4)

(actual time=0.05..0.07 rows=25 loops=1)
 Total runtime: 2085.93 msec
(8 rows)


and

 explain analyze select G.IDS  from A_ACC G , A_VID_DOC VD where
G.IDS_VID_DOC=VD.IDS  and  G.IDS = 1338673 ;
                                                               QUERY
PLAN

-----------------------------------------------------------------------------------------------------------------------------------------

 Merge Join  (cost=1.83..1.97 rows=1 width=12) (actual
time=40.91..2099.13 rows=1 loops=1)
   Merge Cond: ("outer".ids_vid_doc = "inner".ids)
   ->  Index Scan using i_a_acc_ids_vid_doc on a_acc g
(cost=0.00..43706.42 rows=1 width=8) (actual time=40.65..2098.86 rows=1
loops=1)
         Filter: (ids = 1338673)
   ->  Sort  (cost=1.83..1.89 rows=25 width=4) (actual time=0.22..0.22
rows=25 loops=1)
         Sort Key: vd.ids
         ->  Seq Scan on a_vid_doc vd  (cost=0.00..1.25 rows=25 width=4)

(actual time=0.05..0.07 rows=25 loops=1)
 Total runtime: 2099.24 msec
(8 rows)

From time to time the second one is very slow (15-17 sek).

If I execute:

 explain analyze select G.IDS  from A_ACC G where  G.IDS = 1338673 ;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------

 Index Scan using a_acc_pkey on a_acc g  (cost=0.00..3.13 rows=1
width=4) (actual time=0.06..0.06 rows=1 loops=1)
   Index Cond: (ids = 1338673)
 Total runtime: 0.11 msec
(3 rows)

, all is working well.

How can I find the problem?
I have index on A_ACC.IDS_VID_DOC and have vacuum full analyze;
Will it help if I make A_ACC.IDS_VID_DOC not null ?

My problem is that I will execute this query many times and ~ 2 sek  is
very slow for me.

Many thanks and best regards,
ivan.

Re: bad join performance

From
Tom Lane
Date:
pginfo <pginfo@t1.unisoftbg.com> writes:
> I am using pg 7.3.3 on RH 7.3,

Are you certain the server is 7.3.3?  This looks like a mergejoin
estimation bug that was present in 7.3 and 7.3.1, but should be fixed
in 7.3.2 and later.

If it is 7.3.3, I'd like to see the pg_stats rows for
a_acc.ids_vid_doc and a_vid_doc.ids.

            regards, tom lane

Re: bad join performance

From
Stephan Szabo
Date:
On Mon, 18 Aug 2003, pginfo wrote:

> Hi ,
> I am using pg 7.3.3 on RH 7.3,
> dual Athlon
> 1 GB RAM.
>
> I have 2 tables a_acc and a_vid_doc (all PK are int).
>
> sizes:
>
>  select count(IDS) from a_acc;
>   count
> ---------
>  1006772
>
> select count(IDS) from a_vid_doc;
>  count
> -------
>     25
>
> I have problem with the join ot this tables.
> I tryed this examples:
>
>  explain analyze select G.IDS  from A_ACC G   join A_VID_DOC VD
> ON(G.IDS_VID_DOC=VD.IDS)  WHERE G.IDS = 1338673 ;

In general the best index on A_ACC for this kind of query might
be on on A_ACC(IDS, IDS_VID_DOC).  That should allow you to search
by IDS value but still get a sorted order of IDS_VID_DOC to help
the join.

Re: bad join performance

From
pginfo
Date:
Hi tom,
sorry for my bad.
My production server is 7.3.7, but the development is 7.3.1 and I ran the
tests on 7.3.1.

It is courios that on 7.3.1 the query is not constantly bad.
From time to time it is running well.

regards,
ivan.
Tom Lane wrote:

> pginfo <pginfo@t1.unisoftbg.com> writes:
> > I am using pg 7.3.3 on RH 7.3,
>
> Are you certain the server is 7.3.3?  This looks like a mergejoin
> estimation bug that was present in 7.3 and 7.3.1, but should be fixed
> in 7.3.2 and later.
>
> If it is 7.3.3, I'd like to see the pg_stats rows for
> a_acc.ids_vid_doc and a_vid_doc.ids.
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Re: bad join performance

From
Tom Lane
Date:
pginfo <pginfo@t1.unisoftbg.com> writes:
> sorry for my bad.
> My production server is 7.3.7, but the development is 7.3.1 and I ran the
> tests on 7.3.1.

> It is courios that on 7.3.1 the query is not constantly bad.
> From time to time it is running well.

Yeah, the mergejoin estimation bug doesn't bite in every case (if it
did, we'd have found it before release ;-)).  Please update to 7.3.4.

            regards, tom lane

Re: bad join performance

From
pginfo
Date:
Ok,
thanks for the help
and best regards.
ivan.

Tom Lane wrote:

> pginfo <pginfo@t1.unisoftbg.com> writes:
> > sorry for my bad.
> > My production server is 7.3.7, but the development is 7.3.1 and I ran the
> > tests on 7.3.1.
>
> > It is courios that on 7.3.1 the query is not constantly bad.
> > From time to time it is running well.
>
> Yeah, the mergejoin estimation bug doesn't bite in every case (if it
> did, we'd have found it before release ;-)).  Please update to 7.3.4.
>
>                         regards, tom lane