From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Shulgin, Oleksandr" <oleksandr(dot)shulgin(at)zalando(dot)de>, David Steele <david(at)pgmasters(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: More stable query plans via more predictable column statistics |
Date: | 2016-03-09 16:15:16 |
Message-ID: | 25990.1457540116@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On Wed, 2016-03-09 at 12:02 -0300, Alvaro Herrera wrote:
>> Tomas Vondra wrote:
>>> FWIW while looking at the code I noticed that we skip wide varlena
>>> values but not cstrings. Seems a bit suspicious.
>> Uh, can you actually have columns of cstring type? I don't think you
>> can ...
> Yeah, but then why do we handle that in compute_scalar_stats?
If you're looking at what I think you're looking at, we aren't bothering
because we assume that cstrings won't be very wide. Since they're not
toastable or compressable, they certainly won't exceed BLCKSZ.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2016-03-09 16:22:11 | Re: More stable query plans via more predictable column statistics |
Previous Message | hailong.li | 2016-03-09 16:13:33 | Re: the include-timestamp data returned by pg_logical_slot_peek_changes() is always 2000-01-01 in 9.5.1 |