| 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 |