From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Allowing ALTER TYPE to change storage strategy |
Date: | 2020-03-05 22:46:44 |
Message-ID: | 13399.1583448404@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> If not, we probably should bite the bullet and go for #1, since
> I have little doubt that we'll need that someday anyway.
> The trick will be to keep down the cache invalidation overhead...
Here's a version that does it like that. I'm less worried about the
overhead than I was before, because I realized that we already had
a syscache callback for pg_type there. And it was being pretty
stupid about which entries it reset, too, so this version might
actually net out as less overhead (in some workloads anyway).
For ease of review I just added the new TCFLAGS value out of
sequence, but I'd be inclined to renumber the bits back into
sequence before committing.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
0001-alter-type-v6.patch | text/x-diff | 53.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-03-05 22:52:52 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Previous Message | James Coleman | 2020-03-05 22:01:06 | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |