On 20/10/2025 04:36, Michael Paquier wrote:
On Wed, Oct 15, 2025 at 05:39:38PM +0300, Heikki Linnakangas wrote:
We could store xl_crc unaligned. IIRC all the structs that follow that are
already stored unaligned.
If we do just that, would there be any downside in moving xl_crc to be
just after
On Wed, Oct 15, 2025 at 05:39:38PM +0300, Heikki Linnakangas wrote:
> We could store xl_crc unaligned. IIRC all the structs that follow that are
> already stored unaligned.
If we do just that, would there be any downside in moving xl_crc to be
just after xl_prev? That would keep the record assemb
On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
> I'm not sure I agree with the premise that we should try to get rid of
> RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
> alternative, we could easily teach e.g pg_waldump to t
ts own opcode mask, but that's no worse than the
situation we have already.
First let me say that I'm not objecting to this patch. It makes the code
a little bit more clear, which is good, so I think I'm +0.5 on this
overall. With that said:
I'm not sure I agree with the pre
On Fri, Oct 10, 2025 at 9:47 AM Michael Paquier wrote:
>
> On Thu, Oct 09, 2025 at 03:15:11PM +0700, John Naylor wrote:
> > Leaving that up to the rmgr makes sense. One consideration I didn't
> > mention was for xlogstats.c -- "record_stats[rmid][recid]" would get
> > 16x larger if recid could tak
On Mon, Oct 06, 2025 at 04:04:00PM +0700, John Naylor wrote:
> 0004: get rid of RM_HEAP2_ID. This was simple once the prerequisites
> were in place. All of the HEAP2_* macros keep the same name and only
> differ in value. Heap rmgr is completely full so it might be good to
> increase t
On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas wrote:
> This patch consumes one of the padding bytes. That's not entirely free,
> as there is an opportunity cost: we could squeeze out the padding bytes
> and save 2 bytes on every WAL record instead.
I must be misunderstanding, because I'm not
On Thu, Oct 09, 2025 at 03:15:11PM +0700, John Naylor wrote:
> Leaving that up to the rmgr makes sense. One consideration I didn't
> mention was for xlogstats.c -- "record_stats[rmid][recid]" would get
> 16x larger if recid could take up the full byte. Maybe that's
> harmless, but I didn't want to
On 15/10/2025 02:54, Michael Paquier wrote:
On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
I'm not sure I agree with the premise that we should try to get rid of
RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
alternative, we could easily
fferent from
- * the ones above associated with RM_HEAP_ID. XLOG_HEAP_OPMASK applies to
- * these, too.
+ * the ones above associated with RM_HEAP_ID.
*
* There's no difference between XLOG_HEAP2_PRUNE_ON_ACCESS,
* XLOG_HEAP2_PRUNE_VACUUM_SCAN and XLOG_HEAP2_PRUNE_VACUUM_CLEANUP
tps://www.postgresql.org/message-id/CAGjhLkNYhNfbhsZhR_sEJ=1vqjmfczx1bvfwwz0+it2ucqg...@mail.gmail.com
That's also what you are doing here..
> 0004: get rid of RM_HEAP2_ID. This was simple once the prerequisites
> were in place. All of the HEAP2_* macros keep the same name and only
&g
On 15/10/2025 07:51, John Naylor wrote:
On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas wrote:
This patch consumes one of the padding bytes. That's not entirely free,
as there is an opportunity cost: we could squeeze out the padding bytes
and save 2 bytes on every WAL record instead.
I mus
On Wed, Oct 15, 2025 at 12:01:44PM +0700, John Naylor wrote:
> On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier wrote:
>> We could move out xl_xid, which should not be required for all
>> records, shaving 4 bytes from the base XLogRecord. I'm afraid of the
>> duplication this would create if we pu
On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier wrote:
>
> On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
> > I'm not sure I agree with the premise that we should try to get rid of
> > RM_HEAP2_ID. There's nothing wrong with that scheme as suc
On Thu, Oct 9, 2025 at 1:43 PM Michael Paquier wrote:
> > 0001: Split xl_info into xl_info for rmgr-specific info and xl_geninfo
> > for generic flags. I used the XLogInsertExtended() idea from one of
> > Matthias's patches in [3], but wrote the rest a different way to keep
> > churn small.
>
> Re
15 matches
Mail list logo
