| From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
|---|---|
| To: | "jian he" <jian(dot)universality(at)gmail(dot)com> |
| Cc: | "Nathan Bossart" <nathandbossart(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: create table like including storage parameter |
| Date: | 2025-12-18 14:59:39 |
| Message-ID: | 0d2d7026-a34f-44bf-b22d-ae9be5e48575@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 17, 2025, at 3:41 AM, jian he wrote:
> Does the "parameter" (INCLUDING PARAMETERS) definition is close to "option"?
> This raises the question of whether we should also copy column-level options to
> the new table.
>
I don't think so. The current attribute options (n_distinct and
n_distinct_inherited) are closely tied to the data. I'm afraid that this
decision would impose bad plans in the future.
--
Euler Taveira
EDB https://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-12-18 15:18:09 | Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access) |
| Previous Message | Euler Taveira | 2025-12-18 14:49:02 | Re: Improve logical replication usability when tables lack primary keys |