From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Montana Low <montana(at)postgresml(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Increasing IndexTupleData.t_info from uint16 to uint32 |
Date: | 2024-01-18 15:46:46 |
Message-ID: | 2270943.1705592806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Montana Low <montana(at)postgresml(dot)org> writes:
> I've attached a patch that increases IndexTupleData.t_info from 16bits to
> 32bits allowing for significantly larger index tuple sizes.
I fear this idea is a non-starter because it'd break on-disk
compatibility. Certainly, if we were to try to pursue it, there'd
need to be an enormous amount of effort spent on dealing with existing
indexes and transition mechanisms. I don't think you've made the case
why that would be time well spent.
On a micro level, this makes sizeof(IndexTupleData) be not maxaligned,
which is likely to cause problems on alignment-picky hardware, or else
result in space wastage if we were careful to MAXALIGN() everywhere.
(Which we should have been, but I don't care to bet on it.) A lot of
people would be sad if their indexes got noticeably bigger when they
weren't getting anything out of that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2024-01-18 15:49:11 | Re: More new SQL/JSON item methods |
Previous Message | Robert Haas | 2024-01-18 15:42:53 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |