Re: [PERFORM] Queries sometimes take 1000 times the normal time

2003-08-28 Thread Russell Garrett
We have a somewhat similar situation - we're running a fairly constant, but low priority, background load of about 70 selects and 40 inserts per second (batched into fairly large transactions), and on top of that we're trying to run time-sensitive queries for a web site (well two). I should

Re: [PERFORM] Queries sometimes take 1000 times the normal time

2003-08-28 Thread Russell Garrett
The web site queries will jump up one or two orders of magnitude (I have seen a normally 100ms query take in excess of 30 seconds) in duration at seemingly random points. It's not always when the transactions are committing, and it doesn't seem to be during checkpointing either. The same

Re: [PERFORM] Selecting random rows efficiently

2003-08-30 Thread Russell Garrett
Considering that we'd have to index the random field too, it'd be neater in the long term to re-number the primary key. Although, being a primary key, that's foreign-keyed from absolutely everywhere, so that'd probably take an amusingly long time. ...and no we're not from Micronesia, we're from

Re: [PERFORM] [Fwd: Re: Optimize]

2003-11-25 Thread Russell Garrett
with this query I see how much queries running, but the field current_query are free, so i can't see which queries are very slow. You must perform that query with permission of super_user. I've made it in root-account with psql -U postgres - but i can't see the query You must have these

Re: [PERFORM] Update on putting WAL on ramdisk/

2003-12-12 Thread Russell Garrett
WAL on single drive: 7.990 rec/s WAL on 2nd IDE drive: 8.329 rec/s WAL on tmpfs: 13.172 rec/s A huge jump in performance but a bit scary having a WAL that can disappear at any time. I'm gonna workup a rsync script and do some power-off experiments to see how badly it gets mangled. Surely

Re: [PERFORM] TSearch2 vs. Apache Lucene

2005-12-06 Thread Russell Garrett
On 6 Dec 2005, at 16:47, Joshua Kramer wrote: Has anyone ever compared TSearch2 to Lucene, as far as performance is concerned? In our experience (small often-updated documents) Lucene leaves tsearch2 in the dust. This probably has a lot to do with our usage pattern though. For our usage