because the cache will be emptied by high priority multiple new rows,
thus writing to the end anyways.
Yes, but this only happens when you don't have enought spare idle CPU
time. If you are in such situation for long periods, there's nothing you
can do, you already have problems.
I
Tim Allen wrote:
On Thu, 14 Dec 2000, Christopher Kings-Lynne wrote:
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete all the data,
leaving only the forms, etc - you will be left with a 5MB mdb
El Mié 13 Dic 2000 22:24, xuyifeng escribió:
I have this nasty problem too, in early time, I don't know the problem,
but we used it for a while, than we found our table growing too fast
without insert any record( we use update), this behaviour most like M$
MSACCESS database I had used a long
"Ross J. Reedstrom" wrote:
Not to mention the recent thread here about people recovering data that
was accidently deleted, or from damaged db files: the old tuples serve
as redundant backup, in a way. Not a real compelling reason to keep a
non-overwriting smgr, but still a surprise bonus
On Thu, Dec 14, 2000 at 01:16:20PM +, Hannu Krosing wrote:
The Hermit Hacker wrote:
snip
vadim, for v7.2, is planning on re-writing the storage manager to do
proper overwriting of deleted space, which will reduce the requirement for
vacuum to almost never ...
I hope that he does
* Ross J. Reedstrom [EMAIL PROTECTED] [001214 07:57] wrote:
On Thu, Dec 14, 2000 at 12:07:00PM +0100, Zeugswetter Andreas SB wrote:
They all have an overwriting storage manager. The current storage manager
of PostgreSQL is non overwriting, which has other advantages.
There seem to be
The tendency here seems to be towards an improved smgr.
But, it is currently extremely cheap to calculate where a new row
needs to be located physically. This task is *a lot* more expensive
in an overwrite smgr.
I don't agree. If (as I have proposed) the search is made in the
* mlw [EMAIL PROTECTED] [001214 09:30] wrote:
"Martin A. Marques" wrote:
El Mié 13 Dic 2000 16:41, bpalmer escribió:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server
Alfred Perlstein wrote:
If you're talking about vacuum, you really don't want to do this,
No, I'm not talking about vacuum as it is intended now, it's only a
process that scans tables to find available blocks/tuples. It is
virtually optional, if it doesn't run, the database will behave just
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing anything of the sort (that I can
find), so why does pg need it? Any info?
Thanks,
- brandon
b. palmer,
* Martin A. Marques [EMAIL PROTECTED] [001213 15:15] wrote:
El Mié 13 Dic 2000 16:41, bpalmer escribió:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing
bpalmer wrote:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which brought a question to mind: why the need? I looked
at my oracle server and we aren't doing anything of the sort (that I can
find), so why does pg need it? Any info?
Hi,
I'm one
: Martin A. Marques [EMAIL PROTECTED]
To: bpalmer [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Thursday, December 14, 2000 7:08 AM
Subject: Re: [HACKERS] Why vacuum?
El Mié 13 Dic 2000 16:41, bpalmer escribió:
I noticed the other day that one of my pg databases was slow, so I ran
vacuum on it, which
* xuyifeng [EMAIL PROTECTED] [001213 18:54] wrote:
I have this nasty problem too, in early time, I don't know the problem, but we used
it for a while,
than we found our table growing too fast without insert any record( we use update),
this behaviour
most like M$ MSACCESS database I had
On Wed, 13 Dec 2000, bpalmer wrote:
Yes, postgresql requires vacuum quite often otherwise queries and
updates start taking ungodly amounts of time to complete. If you're
having problems because vacuum locks up your tables for too long
you might want to check out:
But why? I don't
But why? I don't know of other databases that need to be 'vacuum'ed. Do
all others just do it internaly on a regular basis?
What am I missing here?
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete all
On Thu, 14 Dec 2000, Christopher Kings-Lynne wrote:
Plenty of other databases need to be 'vacuumed'. For instance, if you have
an ms access database with 5 MB of data in it, and then delete all the data,
leaving only the forms, etc - you will be left with a 5MB mdb file still!
If you then
17 matches
Mail list logo
