From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AW: AW: Adding index flag showing tuple status |
Date: | 2001-05-18 16:08:30 |
Message-ID: | 200105181608.f4IG8Uo28993@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > I wasn't going to delete it, just add a flag to index scans know they
> > don't need to look at the heap table.
>
> If it is only a flag, you would need to go to the same trouble
> that vacuum already goes to (you cannot mark it if someone else
> is still interested in this snapshot). Thus I do not see any
> benefit in adding a flag, versus deleting not needed keys. To
> avoid the snapshot trouble you would need a xid (xmax or
> something), and that is 4 bytes, and not a simple flag.
Yes, I would need:
GetXmaxRecent(&XmaxRecent);
which find the minimum visible transaction for all active backends.
This is currently used in vacuum and btbuild. I would use that
visibility to set the bit. Because it is only a bit, I would need read
lock but not write lock. Multiple people can set the same bit.
Basically, I need to:
add a global XmaxRecent and set it once per transaction if needed
add a parameter to heap_fetch to pass back an index tid
if the heap is not visible to any backend, mark the index flag
update the index scan code to skip returning these flaged entries
Of course, Tom thinks is may not be needed with his new vacuum so I may
never implement it.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-18 16:38:22 | Re: Plans for solving the VACUUM problem |
Previous Message | Tom Lane | 2001-05-18 16:08:07 | Re: Problems with avg on interval data type |