On 10/3/06, ITAGAKI Takahiro <[EMAIL PROTECTED]> wrote:
ITL-like approach is more efficient than per-tuple XIDs
unless all tuples in a page are locked at the same time.
However, MAXTRANS and PCTFREE issues may bother us.
IIRC, the last time I checked Oracle's patents, they pretty much had
the I
On Oct 3, 2006, at 2:23 PM, Gregory Stark wrote:
If the space set aside for these transaction ids is full when
you're inserting
i suppose you could just go back to the FSM for another page. But I
don't see
any way out when you're deleting. You have to mark xmax one way or
another and
if ther
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> ITL-like approach is more efficient than per-tuple XIDs
> unless all tuples in a page are locked at the same time.
> However, MAXTRANS and PCTFREE issues may bother us.
I'm not sure how Oracle gets away with MAXTRANS. Somehow it seems to never
arise
Greg Stark <[EMAIL PROTECTED]> wrote:
> The plan Gavin Sherry and I were discussing at the Code Sprint was to store a
> single "most common xmin" xmin in the per-page special area. Then have a bit
> on each tuple indicating that the xmin isn't present in the tuple and instead
> to use the xmin fr
Greg Stark <[EMAIL PROTECTED]> writes:
> The plan Gavin Sherry and I were discussing at the Code Sprint was to store a
> single "most common xmin" xmin in the per-page special area. Then have a bit
> on each tuple indicating that the xmin isn't present in the tuple and instead
> to use the xmin fro
Tom Lane <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > ... place a limit on the number of transactions that can be live in a table
> > at once.
>
> Urk, well maybe, but ...
>
> > you could shrink all the visibility info to 1 byte if you
> > wanted to.
>
> ... 256
Ühel kenal päeval, E, 2006-10-02 kell 01:30, kirjutas Tom Lane:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > ... place a limit on the number of transactions that can be live in a table
> > at once.
>
> Urk, well maybe, but ...
>
> > you could shrink all the visibility info to 1 byte if you
>
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ... place a limit on the number of transactions that can be live in a table
> at once.
Urk, well maybe, but ...
> you could shrink all the visibility info to 1 byte if you
> wanted to.
... 256 of 'em is surely not an acceptable limit.
On Mon, Oct 02, 2006 at 10:52:48AM +0900, ITAGAKI Takahiro wrote:
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > Dumb question... wouldn't getting down to 20 bytes buy us something?
> >
> > BTW, the apparently useless byte after the 27- or 23-byte hea
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > Dumb question... wouldn't getting down to 20 bytes buy us something?
>
> BTW, the apparently useless byte after the 27- or 23-byte header
> actually has some good use: in a table of up to 8 columns, you can
> fit
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Dumb question... wouldn't getting down to 20 bytes buy us something?
Only on 32-bit machines, which are getting less interesting as database
servers every day. (Just last night I was reading somebody opining that
the transition to 64-bit hardware would
On Fri, Sep 29, 2006 at 01:15:06PM +0900, ITAGAKI Takahiro wrote:
>
> "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> > The reason I thought of this is because once the transaction commits, we
> > have no use for the cid info. So we could do something like have
> > bgwriter look for tuples that bel
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote:
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
We could get rid of t_hoff, because we should always be able to
calculate the header size. Then we
On Fri, Sep 29, 2006 at 10:59:13AM +0100, Heikki Linnakangas wrote:
> Martijn van Oosterhout wrote:
> >On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
> >>We could get rid of t_hoff, because we should always be able to
> >>calculate the header size. Then we're down to 18 bytes.
Martijn van Oosterhout wrote:
On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
We could get rid of t_hoff, because we should always be able to
calculate the header size. Then we're down to 18 bytes.
Without t_hoff, how do you know the size of the null bitmap? You could
proba
On Fri, Sep 29, 2006 at 09:35:31AM +0100, Heikki Linnakangas wrote:
> We could get rid of t_hoff, because we should always be able to
> calculate the header size. Then we're down to 18 bytes.
Without t_hoff, how do you know the size of the null bitmap? You could
probably do it only if you assume
ITAGAKI Takahiro wrote:
However, I think our next goal to shrink the headers is 16 bytes. The
headers
become 23 bytes using phantom cids and we are limited by alignments,
so we will
have no more advantages unless we delete extra 7 bytes in the headers.
...and it seems to be very difficult.
Ye
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> The reason I thought of this is because once the transaction commits, we
> have no use for the cid info. So we could do something like have
> bgwriter look for tuples that belong to committed transactions before it
> writes a page, and strip the cid out
On Thu, Sep 28, 2006 at 05:13:11PM +0100, Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> >In addition to/instead of abstracting cmin/cmax to a phantom ID, what
> >about allowing for two versions of the tuple header, one with cid info
> >and one without? That would allow for cid info to be stripp
Jim C. Nasby wrote:
In addition to/instead of abstracting cmin/cmax to a phantom ID, what
about allowing for two versions of the tuple header, one with cid info
and one without? That would allow for cid info to be stripped out when
pages were written to disk.
How exactly would that help? You
In addition to/instead of abstracting cmin/cmax to a phantom ID, what
about allowing for two versions of the tuple header, one with cid info
and one without? That would allow for cid info to be stripped out when
pages were written to disk.
The downside to this is that we'd have to be able to deal
21 matches
Mail list logo
