Benjamin Smith <[EMAIL PROTECTED]> writes:
> And, this dropped the query time from between 2.2-30 seconds all the
> way down to just 55-ish ms, without any new indexes! What's more, the
> improvement came from a move of a block I thought more or less
> unimportant!
> // tries to put jaw back into
Wow! I did exactly what you suggested, and played with the ordering for about
20-30 minutes. After 10 minutes or so, I'd gotten the response time down to
1700 ms from 2200 ms.
Moving the join conditions up into the "FROM" clause, and dropping the "WHERE"
clause altogether allowed me to reorder
Benjamin Smith <[EMAIL PROTECTED]> writes:
> The example that I gave was a small one to illustrate my understanding of
> multiple foreign keys, indexes and how they work together. (or don't) The
> actual query is quite a bit bigger and nastier. I've considered breaking it
> up into smaller piece
The example that I gave was a small one to illustrate my understanding of
multiple foreign keys, indexes and how they work together. (or don't) The
actual query is quite a bit bigger and nastier. I've considered breaking it
up into smaller pieces, but this query has been extensively tested and
On Sat, 10 Dec 2005, Benjamin Smith wrote:
> A few questions:
>
> 1) Let's assume that I have some multipile foreign keys, and I join on three
> values. For example:
>
> Create table gangsters (
> name varchar not null,
> birthdate integer not null,
> shirtnumber integer not nul
And, it's exactly as fast on the new, dual-proc Opteron as the aging P4. 2.2
seconds. It's literally within 1 ms time! (2,206 ms vs 2,207 ms) Throwing
more RAM at it makes no difference.
WTF??!?!?
Well from a postgres perspective you are still only using one CPU for
this query. Are yo
On Tue, Sep 27, 2005 at 09:07:41AM -0500, boinger wrote:
> -> Index Scan using strafe_group on tasks_applied
> (cost=0.00..6.02 rows=1 width=22) (actual time=0.042..0.043 rows=0
> loops=1188)
>
> Index Cond: ((("outer".modcode)::text =
> (tasks_applied.modcode):
On 9/27/05, Dawid Kuroczko <[EMAIL PROTECTED]> wrote:
> > QUERY PLAN
> > -> GroupAggregate (cost=0.00..85168.65 rows=11
> width=22)
> > (actual time=3149.916..45578.292 rows=515 loops=1)
>
> Hmm, planner expected 11 rows, got 515
>
>
> > (cost=0.00..85167.23 rows=107 width=22) (actual
>
On 9/26/05, boinger <[EMAIL PROTECTED]> wrote:
Hello.I'm not sure if this is a question suited for here, the -sql list, orthe -performance list, so if I'm mis-posting, please direct me to theright list.I was unable to come up with anything relevant from the archives
(though...I am not too sure wher
