Bingo, the smaller the sort_mem, the faster that query is.
Thanks a lot to everybody that helped, i'll tweak with these values
more when I get a chance now that I have some guidelines that make
sense.
Rhett
On 8/9/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Rhett Garber <[EMAIL P
Lane <[EMAIL PROTECTED]> wrote:
> Rhett Garber <[EMAIL PROTECTED]> writes:
> > They are both running SuSE 8, 2.4.21-128-smp kernel
>
> > Compile instructions (I didn't do it myself) indicate we built from
> > source with nothing fancy:
>
> You coul
> I'm now thinking you've got either a platform- or compiler-specific
> problem. Exactly what is the hardware (the CPU not the disks)? How did
> you build or come by the Postgres executables (compiler, configure
> options, etc)?
I've tried it on two of our machines, both HP Proliant DL580:
Produ
stry_id = 40105) AND (obj1
= 73582)) Total runtime: 7.693 ms
(7 rows)
On 8/8/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Rhett Garber <[EMAIL PROTECTED]> writes:
> > This is postgres 7.4.1
> > All the rows involved are integers.
>
> Hmph. There is something really
This is postgres 7.4.1
All the rows involved are integers.
Thanks,
Rhett
On 8/5/05, Tom Lane <[EMAIL PROTECTED]> wrote:
> Rhett Garber <[EMAIL PROTECTED]> writes:
> > Hash Join (cost=5.96..7.04 rows=1 width=14) (actual
> > time=10.591..10.609 rows=1 loops=1)
&g
On 8/5/05, Havasvölgyi Ottó <[EMAIL PROTECTED]> wrote:
> Please post the explain analyze for both queries. From that we can see the
> predicted and the actual costs of them.
> select rtmessagestate.* from rtmessagestate, connection where
> connection_registry_id = 40105 and obj1 = 73582 and obj2
I've got similiar queries that I think should be evaluated (as
displayed through 'explain') the same, but don't.
Hopefully this is the rigth place to send such a question and one of
you can help explain this to me.
The Tables:
Connection - 1.2 million entries, about 60 megs, 3 integer fields
t
