Re: Disk space consumption: character varying(255) versus text usedfor index - Mailing list pgsql-novice

From Marcel Ruff
Subject Re: Disk space consumption: character varying(255) versus text usedfor index
Date
Msg-id 0edae0c2-528a-0bc6-fda1-942f1342e030@netwake.com
Whole thread Raw
In response to RE: Disk space consumption: character varying(255) versus text usedfor index  (Stephen Froehlich <s.froehlich@cablelabs.com>)
List pgsql-novice
Thank you for the hints, this helps a lot.

I love PostgreSQL,

Marcel

Am 21.12.19 um 15:41 schrieb Stephen Froehlich:

Just to make it a little more clear, PostgreSQL has a binary UUID type that should house your GUID’s perfectly efficiently. (It also provides a lot of other useful functionality and speed improvements):

 

https://www.postgresql.org/docs/12/datatype-uuid.html

 

 

 

From: Justin <zzzzz.graf@gmail.com>
Sent: Friday, December 20, 2019 12:06 PM
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: ruff@netwake.com; pgsql-novice@postgresql.org
Subject: Re: Disk space consumption: character varying(255) versus text used for index

 

Have question this states the GUID  is the text Hex value form a UUID  if so that 36bytes long  vs integer that is 128bits   if that is the case convert this GUID to  UUID type 

 

or am i missing something?

 

On Fri, Dec 20, 2019 at 1:55 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Marcel Ruff <ruff@netwake.com> writes:
> my btree index for
>    guid                | character varying(255)
> is currently 6.9GB (almost all guid entries are of size 37bytes)
> If I would change the data type to
>   guid                | text
> would the index size be reduced (without hitting performance)?

Wouldn't make any difference at all.

                        regards, tom lane


--
NetwakeVision
Alte Owinger Straße 100
D-88662 Überlingen
Phone: +49 7551 309372
http://www.netwakevision.com
http://www.royal-gps.com

pgsql-novice by date:

Previous
From: Stephen Froehlich
Date:
Subject: RE: Disk space consumption: character varying(255) versus text usedfor index
Next
From: Mike Dewhirst
Date:
Subject: Re: Renaming sequences