On Wed, Jul 25, 2018 at 10:30 PM, David Rowley <david.row...@2ndquadrant.com> wrote: > I agree RANGE partition is probably the most likely case to benefit > from this optimisation, but I just don't think that HASH could never > benefit and LIST probably sits somewhere in the middle. > > HASH partitioning might be useful in cases like partitioning by > "sensor_id". It does not seem that unreasonable that someone might > want to load all the data for an entire sensor at once.
Another case might be restoring a dump with --load-via-partition-root. Granted, you probably shouldn't specify that option unless you expect rows to end up in different partition than they were in the original cluster, but it's possible somebody might do it out of an abundance of caution if, say, they are doing an automated dump restore on a machine that may or may not have different endian-ness than the original. I think making it adaptive, as you've done, is definitely better than a heuristic based on the partitioning type. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
