|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Alex Shulgin <alex(dot)shulgin(at)gmail(dot)com>|
|Cc:||"Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, David Steele <david(at)pgmasters(dot)net>|
|Subject:||Re: More stable query plans via more predictable column statistics|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Alex Shulgin <alex(dot)shulgin(at)gmail(dot)com> writes:
> On Sun, Apr 3, 2016 at 7:18 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, we have to do *something* with the last (possibly only) value.
>> Neither "include always" nor "omit always" seem sane to me. What other
>> decision rule do you want there?
> Well, what implies that the last value is somehow special? I would think
> we should just do with it whatever we do with the rest of the candidate
Sure, but both of the proposed decision rules break down when there are no
values after the one under consideration. We need to do something sane
> For "the only value" case: we cannot build a histogram out of a single
> value, so omitting it from MCVs is not a good strategy, ISTM.
> From my point of view that amounts to "include always".
If there is only one value, it will have 100% of the samples, so it would
get included under just about any decision rule (other than "more than
100% of this value plus following values"). I don't think making sure
this case works is sufficient to get us to a reasonable rule --- it's
a necessary case, but not a sufficient case.
regards, tom lane
|Next Message||Fabien COELHO||2016-04-03 05:54:16||pgbench more operators & functions|
|Previous Message||Alex Shulgin||2016-04-03 05:42:43||Re: More stable query plans via more predictable column statistics|