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)
Hash Cond: (outer.id = inner.obj2
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 strange going on here. I tried to
duplicate your problem in 7.4.*, thus:
regression
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:
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 could double-check the configure options by running pg_config
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 PROTECTED] writes
