Re: Allowing ALTER TYPE to change storage strategy

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

In response to

Responses

Browse pgsql-hackers by date

  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)