A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (Mike Nolan) wrote:
>> We have a web app with a postgres backend. Most queries have subsecond
>> response times through the web even with high usage. Every once in awhile
>> someone will run either an ad-hoc query or some other long
On Apr 16, 2004, at 4:23 AM, Rajesh Kumar Mallah wrote:
I am running an update on the same table
update rfis set inquiry_status='APPROVED' where inquiry_status='a';
Its running for past 20 mins. and top output is below.
The PID which is executing the query above is 6712. Can anyone
tell m
[ resending because I fat-fingered the cc: to the list ]
I see the problem: all the entries in your work_units column have the
low 32 bits equal to zero.
regression=# select distinct work_units % (2^32)::bigint from Trank_work_overall;
?column?
--
0
(1 row)
The hash function fo
I didn't follow the conversation from the begining, bu I imagine that you
could improve
performance using the value (work_units % (2^32) ) instead of work_units.
You could even make an index on this value. Like that, the HASH function
will work well. This is not a good solution, but ...
For exampl
Tom Lane <[EMAIL PROTECTED]> writes:
> We could change the hash function, perhaps, but then we'd just have
> different cases where there's a problem ... hashing will always fail on
> *some* set of inputs.
Sure, but completely ignoring part of the input seems like an unfortunate
choice of hash fu
It might be worth trying out a build with -O2, just to rule out any -O3
oddness.
regards
Mark
Jim C. Nasby wrote:
PostgreSQL 7.4.2 compiled with -O3.
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> (Also, I have been harboring some notions of supporting cross-type hash
>> joins for integer types, which will not work unless small int8 values hash
>> the same as int4 etc.)
> The obvious way to modify the hash func
On Sat, 17 Apr 2004, Tom Lane wrote:
> *some* set of inputs. (Also, I have been harboring some notions of
> supporting cross-type hash joins for integer types, which will not work
> unless small int8 values hash the same as int4 etc.)
The simple solution would be to always extend integers to 64
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Tom Lane <[EMAIL PROTECTED]> writes:
> >> (Also, I have been harboring some notions of supporting cross-type hash
> >> joins for integer types, which will not work unless small int8 values hash
> >> the same as int4
