Re: Ideas about a better API for postgres_fdw remote estimates
От | Andrey V. Lepikhov |
---|---|
Тема | Re: Ideas about a better API for postgres_fdw remote estimates |
Дата | |
Msg-id | 0a75a7b9-d800-4c70-7eec-7fa7630a854b@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Ideas about a better API for postgres_fdw remote estimates (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Ideas about a better API for postgres_fdw remote estimates
|
Список | pgsql-hackers |
On 8/29/20 9:50 PM, Tom Lane wrote: > Years ago (when I was still at Salesforce, IIRC, so ~5 years) we had > some discussions about making it possible for pg_dump and/or pg_upgrade > to propagate stats data forward to the new database. There is at least > one POC patch in the archives for doing that by dumping the stats data > wrapped in a function call, where the target database's version of the > function would be responsible for adapting the data if necessary, or > maybe just discarding it if it couldn't adapt. We seem to have lost > interest but it still seems like something worth pursuing. I'd guess > that if such infrastructure existed it could be helpful for this. Thanks for this helpful feedback. I found several threads related to the problem [1-3]. I agreed that this task needs to implement an API for serialization/deserialization of statistics: pg_load_relation_statistics(json_string text); pg_get_relation_statistics(relname text); We can use a version number for resolving conflicts with different statistics implementations. "Load" function will validate the values[] anyarray while deserializing the input json string to the datatype of the relation column. Maybe I didn't feel all the problems of this task? 1. https://www.postgresql.org/message-id/flat/724322880.K8vzik8zPz%40abook 2. https://www.postgresql.org/message-id/flat/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA%40mail.gmail.com 3. https://www.postgresql.org/message-id/flat/GNELIHDDFBOCMGBFGEFOOEOPCBAA.chriskl%40familyhealth.com.au -- regards, Andrey Lepikhov Postgres Professional
В списке pgsql-hackers по дате отправления: