On Tue, May 18, 2021 at 01:27:48PM +1200, David Rowley wrote: > A slightly different optimization that I have considered and even > written patches before was to have ExecFindPartition() cache the last > routed to partition and have it check if the new row can go into that > one on the next call. I imagined there might be a use case for > speeding that up for RANGE partitioned tables since it seems fairly > likely that most use cases, at least for time series ranges will > always hit the same partition most of the time. Since RANGE requires > a binary search there might be some savings there. I imagine that > optimisation would never be useful for HASH partitioning since it > seems most likely that we'll be routing to a different partition each > time and wouldn't save much since routing to hash partitions are > cheaper than other types. LIST partitioning I'm not so sure about. It > seems much less likely than RANGE to hit the same partition twice in a > row.
It depends a lot on the schema used and the load pattern, but I'd like to think that a similar argument can be made in favor of LIST partitioning here. -- Michael
signature.asc
Description: PGP signature
