Re: [HACKERS] <> join selectivity estimate question

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] <> join selectivity estimate question
Дата
Msg-id 31950.1505343605@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] <> join selectivity estimate question  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] <> join selectivity estimate question  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Список pgsql-hackers
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Wed, Sep 6, 2017 at 11:14 PM, Ashutosh Bapat
> <ashutosh.bapat@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.
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] <> join selectivity estimate question
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: [HACKERS] psql: new help related to variables are not too readable