Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Speaking of which, I think I've noticed a longer delay in server start
> after initdb. I haven't measured nor profiled it, but I think it may be
> because of the heap_inplace_update xlogging that we weren't doing
> previously.
Can't say that I've notic
Martijn van Oosterhout wrote:
> > You can't truncate a tuple to just the header, or at least it's not
> > going to be very useful to do it, unless you can also move other tuples
> > to coalesce the free space on the page. Which means you need a
> > VACUUM-strength page lock. If you're trying to d
Martijn van Oosterhout wrote:
> One thing I am confused about, currently the ctid chain follows tuple
> history so that transactions can find the latest version of any tuple,
> even if the key fields have changed. This proposal breaks that, I'm not
> sure how important that is though.
No, SITC doe
On Thu, Jun 29, 2006 at 12:35:12PM -0400, Tom Lane wrote:
> Another issue is that this would replace a simple hint-bit setting with
> an index change that requires a WAL entry. There'll be more WAL traffic
> altogether from backends retail-deleting index tuples than there would
> be from VACUUM cl
Tom Lane wrote:
> Another issue is that this would replace a simple hint-bit setting with
> an index change that requires a WAL entry. There'll be more WAL traffic
> altogether from backends retail-deleting index tuples than there would
> be from VACUUM cleaning the whole page at once
Speaking o
Ühel kenal päeval, N, 2006-06-29 kell 12:35, kirjutas Tom Lane:
> Martijn van Oosterhout writes:
> >> Tom - what do you think of the other related idea, that of reusing dead
> >> index entries ?
>
> Possibly workable for btree now that we do page-at-a-time index scans;
> however I'm pretty hesita
Martijn van Oosterhout writes:
>> Tom - what do you think of the other related idea, that of reusing dead
>> index entries ?
Possibly workable for btree now that we do page-at-a-time index scans;
however I'm pretty hesitant to build any large infrastructure atop that
change until we've got more p
> > And anyway, ctid is a usable unique row identifier only within
> > read-only transactions, or not ?
actually for as long as no vacuum comes along. This would change
with SITC. (Maybe it would help to only reuse old versions of the same
row,
then anybody holding a ctid would at least be still
On Thu, Jun 29, 2006 at 01:39:51AM +0300, Hannu Krosing wrote:
> And anyway, ctid is a usable unique row identifier only within read-only
> transactions, or not ?
Err, no. The ctid is the only identifer of a tuple in any case. When
you do a delete, the tuple to be deleted is indicated by the ctid
Ühel kenal päeval, K, 2006-06-28 kell 18:19, kirjutas Tom Lane:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Here is an overview of the SITC method:
> > http://momjian.us/cgi-bin/pgsitc
>
> A pretty fundamental problem is that the method assumes it's OK to
> change the CTID of a live tuple
> > Here is an overview of the SITC method:
> > http://momjian.us/cgi-bin/pgsitc
>
> A pretty fundamental problem is that the method assumes it's
> OK to change the CTID of a live tuple (by swapping its item
> pointer with some expired version). It is not --- this will break:
I am having
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here is an overview of the SITC method:
> http://momjian.us/cgi-bin/pgsitc
A pretty fundamental problem is that the method assumes it's OK to
change the CTID of a live tuple (by swapping its item pointer with some
expired version). It is not --- t
bruce wrote:
> Greg Stark wrote:
> >
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >
> > > PFC wrote:
> > > >
> > > > > My idea is that if an UPDATE places the new tuple on the same page as
> > > > > the old tuple, it will not create new index entries for any indexes
> > > > > where the key do
13 matches
Mail list logo
