> Hi all,
>
> I don't think we're gonna be in war with mSQL or MySQL. They're our pals
> in this crusade. The way of free and open source is really great. No one
> here works for any benefit but we still need to succeed. In here, the
> success declare as the number of user running Postgres which
Matt McClure wrote:
>
> You say that vacuum "re-writes" the database. Does it alter row oids???
^^
No.
> If so, my scheme completely corrupts my database whenever I do a vacuum,
> since in concert and song the row oids would c
> That is the real problem. I have to assume whenever you start implementing raw
> devices, you go far far away from DBMS design to OS design. Perhaps you do not
> have to write the process control part of an OS, but (I mean this jokingly) in
> one's arrogance one must think you can access the
On Tue, 28 Jul 1998, Boersenspielteam wrote:
> Hi,
>
> let me add one thing here ... (if this comes a second time, of missed
> the first one ...)
>
> Wouldn't it be possible to get some backing from one of the
> commercial Linux distribution makers? Like Redhat supports Gnome or
> S.u.S.e su
Yes, but... does postgres maintain some statistics that could be queried
to determine whether vacuuming would be helpful? For Case 1 I would need
to know how many records were added since the last vacuum relative to the
total number of records in each table. For case 2 I guess you really only
nee
Hi,
let me add one thing here ... (if this comes a second time, of missed
the first one ...)
Wouldn't it be possible to get some backing from one of the
commercial Linux distribution makers? Like Redhat supports Gnome or
S.u.S.e supports XFree? What about GNU? Anyone listening?
This would be
I'm relatively new to postgres and I've had a couple of questions for a
while now. This post made me worry about them again:
> 2. the server currently doesn't "reuse" deleted rows, but just keeps
>appending them to the end. running a straight VACUUM will perform a
>de-fragmentation by e
On Tue, 28 Jul 1998, Chris Johnson wrote:
>
> OK, so there's been quite a bit of traffic about vacuuming databases as
> well as more than one suggestion on how to do it. But there really hasn't
> been an answer to the question of how to know when to vacuum.
>
> I now vacuum the databases every
OK, so there's been quite a bit of traffic about vacuuming databases as
well as more than one suggestion on how to do it. But there really hasn't
been an answer to the question of how to know when to vacuum.
I now vacuum the databases every night, but this seems somewhat
inefficient... I know t
> The other problem with trying to implement RAW devices, and,
> granted, I could be over cmplicating it, but how do you implement it
> across X operating systems running Y platforms? Doesn't each of them
> access drives differently? And, in some cases, multiply that by two for
> IDE vs
At 14:46 +0300 on 28/7/98, The Hermit Hacker wrote:
> On Tue, 28 Jul 1998, Herouth Maoz wrote:
>
> > He didn't ask me what the features were. I'm quite willing to specify them.
> > Yes, I'm quite aware that many of them are in the pipeline... But hey, if I
> > install Oracle/Informix, I'd have t
On Tue, 28 Jul 1998, Herouth Maoz wrote:
> He didn't ask me what the features were. I'm quite willing to specify them.
> Yes, I'm quite aware that many of them are in the pipeline... But hey, if I
> install Oracle/Informix, I'd have them all *now*, tested and debugged by
> many users before me.
>
At 11:06 +0300 on 28/7/98, Henning Hucke wrote:
>
> > [... Storing graphics in a postgresql db ...]
> > You can't. There is a limit on the tuple size, restricting it to 8k. If you
> > could guarantee that your images are no more than, say, 1K - I'd say you
> > can uuencode them or translate to h
At 20:20 +0300 on 27/7/98, Chris Johnson wrote:
> Come on - be reasonable... The person that asked if you would be willing
> to pay some money to get the development of features you want was not
> suggesting that you would have a special version of PostgreSQL. Any
> additions made would wind up
> On Sun, 26 Jul 1998, Herouth Maoz wrote:
>
> > At 23:36 +0300 on 24/7/98, Richard Lynch wrote:
> >
> >
> > > Well, let's try crontab -e and mess around to find out the answers to these
> > > questions. Or at least to see if I can just ignore this whole MAILTO thing
> > > for now. I can alwa
> > > >Let's remove the "I don't want to think" utilities like
> > > >{create,destroy}{db,user} and force DBA's to actually use the *proper*
> > > >functions.
>
> IMHO (actually make that IMVeryHO) This is probably a bad idea... We
> should just update the man pages to detail the SQL code
16 matches
Mail list logo
