Re: [PERFORM] bad join performance
Ok, thanks for the help and best regards. ivan. Tom Lane wrote: > pginfo <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PERFORM] bad join performance
pginfo <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PERFORM] bad join performance
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PERFORM] bad join performance
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. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PERFORM] bad join performance
pginfo <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
