| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> |
| Cc: | pgsql-novice(at)postgresql(dot)org |
| Subject: | Re: Explanation of pg_column_size |
| Date: | 2016-08-01 22:13:18 |
| Message-ID: | 18647.1470089598@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> writes:
> Can someone please explain the following to me:
> mse=# with l as (select 0.1::numeric as numlit) select
> pg_column_size(numlit) as sz_numlit, pg_column_size(0.1::numeric) as
> sz_expr from l;
> sz_numlit | sz_expr
> -----------+---------
> 5 | 8
> (1 row)
I think the first case is putting the value into a tuple, which will cause
it to be trimmed to short-header form (1 length byte, 4 payload bytes).
In the other case you're looking at a raw numeric_in result, which will
be in the default 4-byte-length-word format (plus the same 4 payload
bytes). The former would be a more accurate representation of how
big this specific value would be on-disk.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Muller | 2016-08-02 16:48:23 | Column Does Not Exist Error: Order by an Particular Cell of an Array |
| Previous Message | Steve Baldwin | 2016-08-01 21:46:24 | Explanation of pg_column_size |