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
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 subquer
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 t
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
us
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 fo
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 b
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 t
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 i
"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 study.chiliOID=r0.
(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,
You will no doubt hear later from the tuning experts on the list.
However, let me save everybody some time by verifying some basics:
1. When you restructured the database, you ran VACUUM ANALYZE on the new
database (pacs)?
2. You said that you "eliminated the indexes" because they weren'
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 appr
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 i
13 matches
Mail list logo
