On Thu, Sep 14, 2017 at 4:30 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Thomas Munro <thomas.mu...@enterprisedb.com> writes: >> On Wed, Sep 6, 2017 at 11:14 PM, Ashutosh Bapat >> <ashutosh.ba...@enterprisedb.com> wrote: >>> I added some "stable" tests to your patch taking inspiration from the >>> test SQL file. I think those will be stable across machines and runs. >>> Please let me know if those look good to you. > >> Hmm. But they show actual rows, not plan->plan_rows, and although the >> former is interesting as a sanity check the latter is the thing under >> test here. It seems like we don't have fine enough control of >> EXPLAIN's output to show estimated rows but not cost. I suppose we >> could try to capture EXPLAIN's output somehow (plpgsql dynamic >> execution or spool output from psql?) and then pull out just the row >> estimates, maybe with extra rounding to cope with instability. > > Don't have time to think about the more general question right now, > but as far as the testing goes, there's already precedent for filtering > EXPLAIN output --- see explain_sq_limit() in subselect.sql. But I'm > dubious whether the rowcount estimate could be relied on to be perfectly > machine-independent, even if you were hiding costs successfully. >
Are you referring to rounding errors? We should probably add some fuzz factor to cover the rounding errors and cause a diff when difference in expected and reported plan rows is beyond that fuzz factor. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
