Re: [PERFORM] strange query behavior

ok thanks Tom I will alter the statistics and re-analyze the table. Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, December 14, 2006 12:49 PM To: Tim Jones Cc: pgsql-performance

Re: [PERFORM] strange query behavior

693683,834990,854693} | {0.0013,0.0013,0.001,0.001,0.001,0.001,0.001,0.001,0.001,0.001} | {3561,271263,556929,839038,1125682,1406538,1697589,1970463,2226781,25392 41,2810844} | 0.31779 thanks Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message

Re: [PERFORM] strange query behavior

That's what I did and got 8.1.2 ... do you want gcc version etc 3.3.2 powerpc aix5.2 Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Matthew O'Connor [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 5:51 PM To:

Re: [PERFORM] strange query behavior

Looks like 8.1.2 Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 5:37 PM To: Tim Jones Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] strange query

Re: [PERFORM] strange query behavior

- #default_statistics_target = 10 # range 1-1000 #constraint_exclusion = off #from_collapse_limit = 8 #join_collapse_limit = 8# 1 disables collapsing of explicit # JOINs Thanks Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message

Re: [PERFORM] strange query behavior

.00..1.02 rows=6 width=0) (actual time=0.032..0.032 rows=0 loops=1) Index Cond: (batteryidentifier = 1177470) Total runtime: 19275.838 ms (18 rows) Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Tom Lane [mailto:[EMAIL

[PERFORM] strange query behavior

particular index? thanks Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] slow query using sub select

that worked like a champ nice call as always! thanks Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 7:07 PM To: Tim Jones Cc: pgsql-performance@postgresql.org Subject: Re

[PERFORM] slow query using sub select

ttery_code (cost=0.00..19.78 rows=2794 width=0) (actual time=9.514..9.514 rows=27323 loops=94)' ' Index Cond: ((batterycode)::text = ($0)::text)' 'Total runtime: 910.897 ms' Basically I am just trying to display the batterycode with its most recent date. Is

Re: [PERFORM] joining two tables slow due to sequential scan

ok I am retarded :) Apparently I thought I had done analyze on these tables but I actually had not and that was all that was needed. but thanks for the help. Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Dave Dutcher [mailto:[EMAIL

Re: [PERFORM] joining two tables slow due to sequential scan

s=48036 width=0) (actual time=0.201..0.201 rows=3 loops=1) Index Cond: (patientidentifier = 690193) Total runtime: 91166.540 ms Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent:

Re: [PERFORM] joining two tables slow due to sequential scan

27; 'Total runtime: 0.392 ms' note I have done these on a smaller db than what I am using but the plans are the same Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555 -Original Message- From: Scott Marlowe [mailto:[EMAIL PROTECTED] Sent: Friday, Feb

Re: [PERFORM] joining two tables slow due to sequential scan

ssdocumentidentifier)' ' -> Seq Scan on documentversions (cost=0.00..2997.68 rows=96368 width=996)' ' -> Hash (cost=898.62..898.62 rows=482 width=354)' '-> Bitmap Heap Scan on clinicaldocuments (cost=4.69..898.62 rows=482 width=354)'

Re: [PERFORM] joining two tables slow due to sequential scan

OK. I'm gonna make a couple of guesses here: 1: clinicaldocuments.patientidentifier is an int8 and you're running 7.4 or before. -- nope int4 and 8.1 2: There are more rows with clinicaldocuments.patientidentifier= 123 than with documentversions.documentstatus = 'AC'. -- nope generally spe

[PERFORM] joining two tables slow due to sequential scan

ntversions on clinicaldocuments.dssdocumentidentifier= documentversions .documentidentifier where clinicaldocuments.patientidentifier= 123;   does sequential scan what I need is bottom query it is extremely slow ... Any ideas ?   Tim Jones Healthcare Project Manager Optio Software, Inc. (770) 576-3555  

[PERFORM] query plans different for 8.1 on windows and aix

tientconfidentiality, patientmrn, patientfacility, patientssn, patientsex, patientbirthdate   ->  Seq Scan on patient  (cost=1.00..100054250.26 rows=58 width=161)     Filter: ((patientname)::text ~~ 'SMITH%, NA%'::text) Why is postgres using a sequential scan and not the index what parameters do I need to adjust   thanks Tim Jones Optio Software