On Sun, 21 Apr 2002, Tom Lane wrote:
> At this point you're essentially arguing that it's faster to recompute
> the list of item sizes than it is to read it off disk. Given that the
> recomputation would require sorting the list of item locations (with
> up to a couple hundred entries --- more t
Curt Sampson <[EMAIL PROTECTED]> writes:
> Yes, this uses a bit more CPU, but I think it's going to be a pretty
> trivial amount. It's a short list, and since you're touching the data
> anyway, it's going to be in the CPU cache. The real cost you'll pay is
> in the time to access the area of memor
Curt Sampson <[EMAIL PROTECTED]> writes:
> If this is the case, would it be possible to number the commands
> per-transaction, rather than globally?
They are.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9
> Having per-transaction command IDs might allow us to reduce the
range of
> the t_cmin and t_cmax fields. Unfortunately, probably by not all
that
> much, since one doesn't want to limit the number of commands within
a
> single transaction to something as silly as 65536.
If you can figure out how
On Sat, 20 Apr 2002, Tom Lane wrote:
> >> I believe we do want to distinguish three states: live tuple, dead
> >> tuple, and empty space. Otherwise there will be cases where you're
> >> forced to move data immediately to collapse empty space, when there's
> >> not a good reason to except that yo
On Sat, 20 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > While we're at it, would someone have the time to explain to me
> > how the on-disk CommandIds are used?
>
> To determine visibility of tuples for commands within a transaction.
> Just as you don't want your trans
Curt Sampson <[EMAIL PROTECTED]> writes:
> While we're at it, would someone have the time to explain to me
> how the on-disk CommandIds are used?
To determine visibility of tuples for commands within a transaction.
Just as you don't want your transaction's effects to become visible
until you comm
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> Well, from my examination of the on-disk data the CTID stored there is the
> same as its location in the file, so it could just be filled in while
> reading.
Nope. CTID is used as a forward link from an updated tuple to its newer
version.
On Sat, Apr 20, 2002 at 05:22:20PM +0900, Curt Sampson wrote:
> > ...and 6 bytes for the CTID, which I guess may be unnecessary.
>
> Really? How would things work without it?
Well, from my examination of the on-disk data the CTID stored there is the
same as its location in the file, so it could
[Moved from general to -hackers.]
On Sat, 20 Apr 2002, Martijn van Oosterhout wrote:
> > In MS SQL server, for example
>
> Where is the information needed to determine visibility for transactions? In
> Postgres that's at least 16 bytes (cmin,cmax,xmin,xmax). How does SQL server
> do that?
S
[I've moved this discussion about changing the line pointer from four
bytes to two from -general to -hackers, since it's fairly technical.
The entire message Tom is responding to is appended to this one.]
On Sat, 20 Apr 2002, Tom Lane wrote:
> Curt Sampson <[EMAIL PROTECTED]> writes:
> > ... The
11 matches
Mail list logo
