Re: Hash Functions
Joe Conway <mail@joeconway.com>
From: Joe Conway <mail@joeconway.com>
To: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>
Cc: Andres Freund <andres@anarazel.de>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
Yugo Nagata <nagata@sraoss.co.jp>, amul sul <sulamul@gmail.com>,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2017-06-02T14:19:11Z
Lists: 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
Commits
-
Introduce 64-bit hash functions with a 64-bit seed.
- 81c5e46c490e 11.0 landed
-
Create a "sort support" interface API for faster sorting.
- c6e3ac11b60a 9.2.0 cited
-
Add seven kanji characters defined in the Windows 950 codepage to our
- 2dbbf33f4a95 8.4.0 cited