Re: Allowing ALTER TYPE to change storage strategy
От | Tomas Vondra |
---|---|
Тема | Re: Allowing ALTER TYPE to change storage strategy |
Дата | |
Msg-id | 20200306134218.rgcaddnbcudcu5hm@development обсуждение исходный текст |
Ответ на | Re: Allowing ALTER TYPE to change storage strategy (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Allowing ALTER TYPE to change storage strategy
|
Список | pgsql-hackers |
On Thu, Mar 05, 2020 at 05:46:44PM -0500, Tom Lane wrote: >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. > LGTM. If I had to nitpick, I'd say that the example in docs should be ALTER TYPE mytype SET ( SEND = mytypesend, RECEIVE = mytyperecv ); i.e. with uppercase SEND/RECEIVE, because that's how we spell it in other examples in CREATE TYPE etc. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: