Re: stawidth inconsistency with all NULL columns - Mailing list pgsql-hackers

From Joe Conway
Subject Re: stawidth inconsistency with all NULL columns
Date
Msg-id 19979fb1-0cd8-2a22-8529-e08808ac7983@joeconway.com
Whole thread Raw
In response to Re: stawidth inconsistency with all NULL columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stawidth inconsistency with all NULL columns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 5/21/19 3:55 PM, Tom Lane wrote:
> Joe Conway <mail@joeconway.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


Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: PG 12 draft release notes
Next
From: Robert Haas
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs