Re: [HACKERS] Custom compression methods
От | David Steele |
---|---|
Тема | Re: [HACKERS] Custom compression methods |
Дата | |
Msg-id | 59c51475-c601-7ecc-9af2-d1318090c6d8@pgmasters.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] Custom compression methods (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Custom compression methods
|
Список | pgsql-hackers |
On 3/30/21 10:30 AM, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Mar 24, 2021 at 2:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> But let's ignore the case of pg_upgrade and just consider a dump/restore. >>> I'd still say that unless you give --no-toast-compression then I would >>> expect the dump/restore to preserve the tables' old compression behavior. >>> Robert's argument that the pre-v14 database had no particular compression >>> behavior seems nonsensical to me. We know exactly which compression >>> behavior it has. > >> I said that it didn't have a state, not that it didn't have a >> behavior. That's not exactly the same thing. But I don't want to argue >> about it, either. It's a judgement call what's best here, and I don't >> pretend to have all the answers. If you're sure you've got it right >> ... great! > > I've not heard any other comments about this, but I'm pretty sure that > preserving a table's old toast behavior is in line with what we'd normally > expect pg_dump to do --- especially in light of the fact that we did not > provide any --preserve-toast-compression switch to tell it to do so. > So I'm going to go change it. It looks like this CF entry should have been marked as committed so I did that. Regards, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: