AW: postgres 7.2 features.

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Mikheev, Vadim'" <vmikheev(at)SECTORBASE(dot)COM>, "'Chris Bitmead'" <chrisb(at)nimrod(dot)itg(dot)telstra(dot)com(dot)au>
Cc: pgsql-hackers(at)hub(dot)org
Subject: AW: postgres 7.2 features.
Date: 2000-07-12 16:57:57
Message-ID: 11C1E6749A55D411A9670001FA687963368005@sdexcsrv1.f000.d0188.sd.spardat.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> Note that I don't talk about overwriting/non-overwriting smgr at all!
> It's not issue. There are no problems with keeping dead
> tuples in files
> as long as required. When I told about new smgr I meant
> ability to re-use
> space without vacuum and store > 1 tables per file.
> But I'll object storing transaction commit times in tuple header and
> old-designed pg_time. If you want to do TT - welcome... but make
> it optional, without affect for those who need not in TT.

Thank you for explaining, I did not see that as a possibility.
Now, if we had a possibility to tune/specify what is allowed to be
overwritten, then an online OS backup would still be possible
with that design, maybe even some limited TT.

But: I do think that if we are going towards overwrite smgr, then the
only way that we also gain the advantages of it, is to update inplace.
1. index update only if indexed column changes
2. reduce IO (many updates to one row --> only one data write)

Andreas

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB 2000-07-12 16:58:28 AW: Vacuum only with 20% old tuples
Previous Message Philip Warner 2000-07-12 16:51:04 Re: Insert..returning (was Re: Re: postgres TODO)