Hi, Maxim, and Happy New Year!
On Mon, 1 Jan 2024 at 10:15, Maxim Orlov wrote:
> On Fri, 29 Dec 2023 at 16:36, Matthias van de Meent <
> boekewurm+postg...@gmail.com> wrote:
>
>>
>> I don't think this is an actionable change, as this wastes 4 more bytes
>> (or 8 with alignment) in nearly all
On 1/2/24 1:58 PM, Robert Haas wrote:
Maybe this analysis I've just given isn't quite right, but my point is
that we should try to think hard about where in the system 32-bit XIDs
suck and for what reason, and use that as a guide to what to change
first.
Very
On Mon, Jan 1, 2024 at 1:15 AM Maxim Orlov wrote:
> Yeah, obviously, this is patch make WAL bigger. I'll try to look into the
> idea of fxid calculation, as mentioned above.
> It might in part be a "chicken and the egg" situation. It is very hard to
> split overall 64xid patch into smaller
On Fri, 29 Dec 2023 at 16:36, Matthias van de Meent <
boekewurm+postg...@gmail.com> wrote:
>
> I don't think this is an actionable change, as this wastes 4 more bytes
> (or 8 with alignment) in nearly all WAL records that don't use the
> HEAP/HEAP2/XLOG rmgrs, which would then be up to 10 (if not
On Fri, Dec 29, 2023 at 02:36:19PM +0100, Matthias van de Meent wrote:
> I don't think this is an actionable change, as this wastes 4 more bytes (or
> 8 with alignment) in nearly all WAL records that don't use the
> HEAP/HEAP2/XLOG rmgrs, which would then be up to 10 (if not 14, when
>
On Fri, 29 Dec 2023, 13:49 Maxim Orlov, wrote:
> Hi!
>
> As were discussed in [0] our overall goal is to make Postgres 64 bit
> XIDs. It's obvious, that such a big patch set
> couldn't possible to commit "at once". SLUR patch set [1] was committed a
> short while ago as a first significant
>
Hi!
As were discussed in [0] our overall goal is to make Postgres 64 bit XIDs.
It's obvious, that such a big patch set
couldn't possible to commit "at once". SLUR patch set [1] was committed a
short while ago as a first significant
step in this direction.
This thread is a next step in this
