Re: [HACKERS] Hash Functions
От | Joe Conway |
---|---|
Тема | Re: [HACKERS] Hash Functions |
Дата | |
Msg-id | 4964c23b-f701-ce5b-91f9-6201ece36a26@joeconway.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Hash Functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Hash Functions
|
Список | pgsql-hackers |
On 06/02/2017 05:47 AM, Robert Haas wrote: > On Fri, Jun 2, 2017 at 1:24 AM, Jeff Davis <pgsql@j-davis.com> wrote: >> 2. I basically see two approaches to solve the problem: >> (a) Tom suggested at PGCon that we could have a GUC that >> automatically causes inserts to the partition to be re-routed through >> the parent. We could discuss whether to always route through the >> parent, or do a recheck on the partition constrains and only reroute >> tuples that will fail it. If the user gets into trouble, the worst >> that would happen is a helpful error message telling them to set the >> GUC. I like this idea. > > Yeah, that's not crazy. I find it a bit surprising in terms of the > semantics, though. SET > when_i_try_to_insert_into_a_specific_partition_i_dont_really_mean_it = > true? Maybe SET partition_tuple_retry = true; -or- SET partition_tuple_reroute = true; ? I like the idea of only rerouting when failing constraints although I can envision where there might be use cases where you essentially want to re-partition and therefore reroute everything, leading to: SET partition_tuple_reroute = (none | error | all); Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
В списке pgsql-hackers по дате отправления: