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
Hello,
I just have installed Vadim's patch for speeding up vacuum.
And have quite strange problem.
I have quite small table:
[root@mx src]# ls -l /home/postgres/data/base/db/users*
-rw--- 1 postgres postgres 4120576 Dec 14 08:48
/home/postgres/data/base/db/users
-rw--- 1 postgres
Bruce Momjian wrote:
Bruce Momjian writes:
ERROR: triggered data change violation on relation "primarytest2"
We're getting this report about once every 48 hours, which would make it a
FAQ. (hint, hint)
First time I heard of it. Does anyone know more details?
Think I
"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
when doing txlog switches there seems to be a problem with remembering the
correct = active logfile, when the postmaster crashes.
This is one of the problems I tried to show up previously:
You cannot rely on writes to other files except the txlog itself !!!
Why? If you handle those files
* 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 have obtained the CRC-64 code used in the SWISS-PROT genetic
database:
ftp://ftp.ebi.ac.uk/pub/software/swissprot/Swissknife/SPcrc.tar.gz
(Thanks go to Henning Hermjakob [EMAIL PROTECTED] of the European
Bioinformatics Institute.) From the README:
The code in this package has been
Hi,
I have written a 'C' function to be called during INSERT trigger on a
table.
Are there any restrictions on the functions that can be called?
I know you can call SPI_* functions. But, can I call PQ* functions ?
e.g PQsetdb.
Is there any document which describes how the
On Thursday 14 December 2000 23:04, Vadim Mikheev wrote:
I wouldn't consider it's a bug, but from my point of view it is quite
strange. Any comments?
BTW, I did a backup, and can supply anyone interested with original
table.
Please send it me.
Another small comment. I did not made
14 matches
Mail list logo
