Re: Save a few bytes in pg_attribute
От | Tomas Vondra |
---|---|
Тема | Re: Save a few bytes in pg_attribute |
Дата | |
Msg-id | 09ce1c98-bb98-d374-09b3-50e61e2e29f5@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Save a few bytes in pg_attribute (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Save a few bytes in pg_attribute
|
Список | pgsql-hackers |
On 3/20/23 15:37, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> After the discussion in [0] ff., I was looking around in pg_attribute >> and noticed that we could possibly save 4 bytes. We could change both >> attstattarget and attinhcount from int4 to int2, which together with >> some reordering would save 4 bytes from the fixed portion. > >> attstattarget is already limited to 10000, so this wouldn't lose >> anything. For attinhcount, I don't see any documented limits. But it >> seems unlikely to me that someone would need more than 32k immediate >> inheritance parents on a column. (Maybe an overflow check would be >> useful, though, to prevent shenanigans.) > >> The attached patch seems to work. Thoughts? > > I agree that attinhcount could be narrowed, but I have some concern > about attstattarget. IIRC, the limit on attstattarget was once 1000 > and then we raised it to 10000. Is it inconceivable that we might > want to raise it to 100000 someday? > Yeah, I don't think it'd be wise to make it harder to increase the statistics target limit. IMHO it'd be much better to just not store the statistics target for attributes that have it default (which we now identify by -1), or for system attributes (where we store 0). I'd bet vast majority of systems will just use the default / GUC value. So if we're interested in saving these bytes, we could just store NULL in these cases, no? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: