-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I having the same problem I told here a few weeks before. Database is
using too much resources again.
I do a vacumm full each day, but seems it is not working. I am preparing
an update to postgres 8.2.4 (actually I am using at 8.1.3, and tests f
Craig James <[EMAIL PROTECTED]> writes:
> If I delete a whole bunch of tables (like 10,000 tables), should I vacuum
> system tables, and if so, which ones? (This system is still on 8.1.4 and
> isn't running autovacuum).
"All of them" would do for a first approximation.
If I delete a whole bunch of tables (like 10,000 tables), should I vacuum
system tables, and if so, which ones? (This system is still on 8.1.4 and isn't
running autovacuum).
Thanks,
Craig
---(end of broadcast)---
TIP 4: Have you searched our lis
Hi Josh,
On 9/10/07 2:26 PM, "Josh Berkus" <[EMAIL PROTECTED]> wrote:
> So, when is this getting contributed? ;-)
Yes, that's the right question to ask :-)
One feeble answer: "when we're not overwhelmed by customer activity"...
- Luke
---(end of broadcast)--
Hi Mark, Greg,
On 9/10/07 3:08 PM, "Mark Mielke" <[EMAIL PROTECTED]> wrote:
> One suggestion: The plan is already in a tree. With some dependency analysis,
> I assume the tree could be executed in parallel (multiple threads or event
> triggered entry into a state machine), and I/O to fetch index
Scott Marlowe wrote:
On 9/10/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
Should be a lot higher, something like 10-15 is approximating accurate.
Most people's experience is that due to Postgres underestimating the benefits
of caching
Gregory Stark wrote:
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
Increasing the number of disks in a RAID actually makes the number higher,
not lower. Until Postgres gets AIO + the ability to post multiple
concurrent IOs on index probes, random IO does not scale with increasing
disk count, b
On Mon, 2007-09-10 at 22:44 +0100, Gregory Stark wrote:
> What I don't understand is the bit about "until Postgres gets AIO + the
> ability to post multiple concurrent IOs on index probes". Even with AIO your
> seek times are not going to be improved by wide raid stripes. And you can't
> possibly f
On 9/10/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
>
> "Luke Lonergan" <[EMAIL PROTECTED]> writes:
>
> > Should be a lot higher, something like 10-15 is approximating accurate.
>
> Most people's experience is that due to Postgres underestimating the benefits
> of caching lowering the random_page_
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> Should be a lot higher, something like 10-15 is approximating accurate.
Most people's experience is that due to Postgres underestimating the benefits
of caching lowering the random_page_cost is helpful.
> Increasing the number of disks in a RAID act
Luke,
> We (GP) have implemented
> something we call "Adaptive Nested Loop" to replace a nested loop +
> index scan with a hash join when the selectivity estimates are off in
> order to improve this behavior. We also run with a
> "random_page_cost=100" because we generally run on machines with f
Luke Lonergan wrote:
Should be a lot higher, something like 10-15 is approximating accurate.
In my own case, I have a much smaller database that I normally work
with, where everything should fit in memory (100 Mbytes?), and reducing
it to 3.0 has resulted in consistently better timings for m
Should be a lot higher, something like 10-15 is approximating accurate.
Increasing the number of disks in a RAID actually makes the number higher,
not lower. Until Postgres gets AIO + the ability to post multiple
concurrent IOs on index probes, random IO does not scale with increasing
disk count,
Can anyone answer this for me: Although I realize my client's disk subsystem
(SCSI/RAID Smart Array E200 controller using RAID 1) is less than
impressive - is the default setting of 4.0 realistic or could it be lower?
Thanks!
---(end of broadcast)--
14 matches
Mail list logo
