On Tue, 2004-05-25 at 15:53, Vitaly Belman wrote:
QUERY PLAN
--
Limit (cost=2337.41..2337.43 rows=10 width=76) (actual
time=7875.000..7875.000 rows=10 loops=1)
- Sort (cost=2337.41..2337.94 rows=214 width=76) (actual
time=7875.000..7875.000 rows=10 loops=1)
Hello Marty, Nick and Robert,
NB Depending on what version of PG you are running, IN might take a while
NB to complete. If so try an EXISTS instead
RT A question and two experiments... what version of postgresql is this?
I am using the newer 7.5dev native Windows port. For this reason I
don't
Vitaly,
I am using the newer 7.5dev native Windows port. For this reason I
don't think that IN will cause any trouble (I read that this issue was
resolved in 7.4).
Well, for performance, all bets are off for the dev Windows port. Last I
checked, the Win32 team was still working on
Mario Soto wrote:
Hi. i hava a postresql 7.4.2 in a production server.
tha machine is a Pentium IV 2,6 GHZ AND 1 GB IN RAM with lINUX RH 9.0.
Mario,
Start with reading this:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
Without knowing anything about the size of your database,
[EMAIL PROTECTED] (Neil Conway) writes:
Christopher Browne wrote:
One of our sysadmins did all the configuring OS stuff part; I don't
recall offhand if there was a need to twiddle something in order to
get it to have great gobs of shared memory.
FWIW, the section on configuring kernel
[EMAIL PROTECTED] (Dan Harris) writes:
Christopher Browne wrote:
We have a couple of these at work; they're nice and fast, although the
process of compiling things, well, makes me feel a little unclean.
Thanks very much for your detailed reply, Christopher. Would you mind
elaborating on the
