Re: stawidth inconsistency with all NULL columns

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: stawidth inconsistency with all NULL columns
Date: 2019-05-21 20:07:50
Message-ID: 19979fb1-0cd8-2a22-8529-e08808ac7983@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/21/19 3:55 PM, Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>> else if (null_cnt > 0)
>> {
>> /* We found only nulls; assume the column is entirely null */
>> stats->stats_valid = true;
>> stats->stanullfrac = 1.0;
>> if (is_varwidth)
>> stats->stawidth = 0; /* "unknown" */
>> else
>> stats->stawidth = stats->attrtype->typlen;
>> stats->stadistinct = 0.0; /* "unknown" */
>> }
>> 8<-----------------
>
>> So apparently intentional, but seems gratuitously inconsistent. Could
>> this cause any actual inconsistent behaviors? In any case that first
>> comment does not reflect the code.
>
> Are you suggesting that we should set stawidth to zero even for a
> fixed-width datatype? That seems pretty silly. We know exactly what
> the value should be, and would be if we'd chanced to find even one
> non-null entry.

Well you could argue in similar fashion for variable width values -- if
we find even one of those, it will be at least 4 bytes. So why set those
to zero?

Not a big deal, but it struck me as odd when I was looking at the
current state of affairs.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-05-21 20:13:12 Re: POC: Cleaning up orphaned files using undo logs
Previous Message Andres Freund 2019-05-21 19:57:56 Re: PG 12 draft release notes