If your nightly process is heavily read-only, then raid5 is probably
fine. If however, there is a significant write component then it would
perhaps be worth getting another disk and converting to raid10
(alternatively - see previous postings about raid cards with on-board
cache). Are you seeing
Josh Berkus <[EMAIL PROTECTED]> writes:
>> monitor=# explain analyze select * from "eventtable" where timestamp >
>> CURRENT_TIMESTAMP - INTERVAL '10 minutes';
> Hmmm. What verison of PostgreSQL are you running? I seem to remember an
> issue in one version with selecting comparisons against now
Ilia,
> If I create btree index on all columns (A,B,C..), here is what explain
> analyze gives me:
> -
> Index Scan using all_ind on test2 (cost=0.00..4.51 rows=1 width=24)
> (actual ti me=0.000..0.000 rows=5 loops=1)
>Index Con
Harmon,
> A "VACUUM FULL ANALYZE" is performed every 3 hours.
The FULL part should not be necessary if you've set your max_fsm_pages high
enough.
> Given there are 10080 minutes per week, the planner could, properly
> configured, estimate the number of rows returned by such a query to be:
>
>
Tom Lane mentioned :
=> Turn off
=> memory overallocation in your kernel to get more stable behavior when
=> pushing the limits of available memory.
I think this will already help a lot.
Thanks!!
=> If your concern is with a single nightly process, then that quad Xeon is
=> doing squat for you, b
Stef <[EMAIL PROTECTED]> writes:
> It seems I was mistaking, as I started getting these kind of errors in dmesg :
> VM: killing process postmaster
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
> VM: killing process postmaster
This
Hi all,
I'm running postgres 7.3.4 on a quad Xeon 2.8 GHz with
Mem: 1057824768 309108736 7487160320 12242944 256413696
Swap: 518053888 8630272 509423616
on Linux version 2.4.26-custom
Data directory is mounted with noatime.
Nothing else but one 11GB database is running on this mach
One more point for your list:
Choose Slony if Replicator doesn't support your platform. :-)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED] Rockville, MD +1-301-869-4449 x806
