Hi Helio,
Sorry about the parenthesis - Bad copy/pasting skills! To further discuss
your suggestion: Wouldn't adding n_issue=i.id as a where clause filter cause
the sub-query to become correlated and thus much less efficient ? I may be
wrong, or may have miss-understood your suggestion.
Thanks
Cheers for you help guys. Having filtered and then joined has substantially
reduced the run time.
Much obliged,
Sebastian
On Mon, Nov 10, 2008 at 12:32 PM, Richard Huxton [EMAIL PROTECTED] wrote:
Sebastian Ritter wrote:
Could it have something
to do with the fact that it is a subquery and
Hi all,
I was hoping to receive some advise on a slow running query in our business'
Issue Tracking System. To shed some light on the below mentioned queries,
here is a brief summary of how users interact with the system. The two main
components in the system are a Issues and Followups. An Issue
Richard Huxton wrote:
Do you have an index on (id,dt_modified) for manage_followup? Can you
provide an EXPLAIN ANALYSE for this?
Hi Richard,
Firstly, thank-you very much for your swift reply. To answer your
question,
I had not been using an index on dt_modfied. I have added it now and
Hi Sebastian,
- First of all i think there is an open-parenthesis missing in the query
V2.
Maybe in the V2 version you cold restrict the results in the INNER query a
bit more if you use a restriction clause like WHERE n_issue = i.id in
that. It will certainly lower the number of rows returned by
Sebastian Ritter wrote:
A lot of the reports our technical officers submit to us include a listing
of all actioned issues for a given day along with the last modified followup
of each said issue. With the number of rows in our database increasing at a
high rate, these queries are starting to
Cheers for this Richard. The more I think about it, I believe the join is
being made against ALL issues and followups first and then filtered by my
where clause conditions afterwards. This would in incur a scan against all
15,000 issues and 95,000 followups. Set theory tells me that I should not
Sebastian Ritter wrote:
Could it have something
to do with the fact that it is a subquery and thus the planner can not
deduce filtering conditions from the outer query against it? My apologises
if that made no sense.
Could make a difference.
In summary, what im trying to understand is the
(Here again; my email adress was killed)
Hallo !
I want to tune a database. There a many redundant datas in the database
, because of all the relations were consider as n:m relations. But the
most of them are 1:n Relations. So my approach was to cut the
redundancies to get more performance. But
David M. Richter [EMAIL PROTECTED] writes:
The query with the 3 tables is faster than the query with 2 tables.
How you figure that?
time psql -d compare -c SELECT patient.*,study.* FROM
patient,study,relpatient_study000 r0 WHERE
(patient.chiliOID=r0.parentOID AND
Hallo !
I want to tune a database. There a many redundant datas in the database
, because of all the relations were consider as n:m relations. But the
most of them are 1:n Relations. So my approach was to cut the
redundancies to get more performance. But .. happens!
The query with the 3 tables
What version are you using? (dbPG95GetIndex?)
On Thu, 19 Jul 2001, David M. Richter wrote:
Hallo !
I want to tune a database. There a many redundant datas in the database
, because of all the relations were consider as n:m relations. But the
most of them are 1:n Relations. So my approach
12 matches
Mail list logo
