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 it
> 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.
Su
>>> 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 m
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 ev
>> 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
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 emphasi
