Re: [HACKERS] path toward faster partition pruning
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] path toward faster partition pruning |
Дата | |
Msg-id | 20180407040923.gmv56jq3wrp5pten@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] path toward faster partition pruning (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] path toward faster partition pruning
Re: [HACKERS] path toward faster partition pruning Re: [HACKERS] path toward faster partition pruning |
Список | pgsql-hackers |
Hi, On 2018-04-07 15:49:54 +1200, David Rowley wrote: > Right, I suggest we wait and see if all members go green again as a > result of 40e42e1024c, and if they're happy then we could maybe leave > it as is with the 2 alternatives output files. At least the first previously borked animal came back green (termite). > I don't particularly think it matters which hash partition a tuple > goes into, as long as the hash function spreads the values out enough > and most importantly, the pruning code looks for the tuple in the > partition that it was actually inserted into in the first place. > Obviously, we also want to ensure we never do anything which would > change the matching partition in either minor or major version > upgrades too. +1 I've also attempted to fix rhinoceros's failure I remarked upon a couple hours ago in https://postgr.es/m/20180406210330.wmqw42wqgiicktli@alap3.anarazel.de Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: