Re: parse partition strategy string in gram.y - Mailing list pgsql-hackers

From Finnerty, Jim
Subject Re: parse partition strategy string in gram.y
Date
Msg-id D73B7D77-1194-4A42-ACF3-79FB27687E03@amazon.com
Whole thread Raw
In response to Re: parse partition strategy string in gram.y  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
It will often happen that some hash keys are more frequently referenced than others.  Consider a scenario where
customer_idis the hash key, and one customer is very large in terms of their activity, like IBM, and other keys have
muchless activity.  This asymmetry creates a noisy neighbor problem.  Some partitions may have more than one noisy
neighbor,and in general it would be more flexible to be able to divide the work evenly in terms of activity instead of
evenlywith respect to the encoding of the keys.
 

On 10/24/22, 8:50 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you
canconfirm the sender and know the content is safe.
 



    Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
    > On 2022-Oct-24, Finnerty, Jim wrote:
    >> The advantage of hash partition bounds is that they are not
    >> domain-specific, as they are for ordinary RANGE partitions, but they
    >> are more flexible than MODULUS/REMAINDER partition bounds.

    I'm more than a bit skeptical of that claim.  Under what
    circumstances (other than a really awful hash function,
    perhaps) would it make sense to not use equi-sized hash
    partitions?  

<snip>

                            regards, tom lane


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Fix gin index cost estimation
Next
From: Tom Lane
Date:
Subject: Re: Fix gin index cost estimation