Hi, Thanks for your work, our prototype runs OK. PostgreSQL 11 and its now fully functional partitioning feature is our validated choice to replace a well-known proprietary RDBMS in 100+ public hospitals for our dss application. Best regards Phil
________________________________ De : Amit Langote <langote_amit...@lab.ntt.co.jp> Envoyé : jeudi 9 août 2018 06:35 À : Tom Lane Cc : David Rowley; Rushabh Lathia; Alvaro Herrera; Robert Haas; Phil Florent; PostgreSQL Hackers Objet : Re: Internal error XX000 with enable_partition_pruning=on, pg 11 beta1 on Debian On 2018/08/09 13:00, Tom Lane wrote: > Amit Langote <langote_amit...@lab.ntt.co.jp> writes: >> One reason why we should adapt such a test case is that, in the future, we >> may arrange for make_partitionedrel_pruneinfo(), whose code we just fixed, >> to not be called if we know that run-time pruning is not needed. It seems >> that that's true for the test added by the commit, that is, it doesn't >> need run-time pruning. > > Not following your argument here. Isn't make_partition_pruneinfo > precisely what is in charge of figuring out whether run-time pruning > is possible? With the current coding, yes, it is... > (See my point in the other thread about Jaime's assertion crash, > that no run-time pruning actually would be possible for that query. > But we got to the assertion failure anyway.) The first time I'd seen that make_partition_pruneinfo *always* gets called from create_append_plan if rel->baserestrictinfo is non-NIL, I had wondered whether we couldn't avoid doing it for the cases for which we'll end up throwing away all that work anyway. But looking at the code now, it may be a bit hard -- analyze_partkey_exprs(), which determines whether we'll need any execution-time pruning, could not be called any sooner. So, okay, I have to admit that my quoted argument isn't that strong. Thanks, Amit
