Re: What is the maximum encoding-conversion growth rate, anyway? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: What is the maximum encoding-conversion growth rate, anyway?
Date
Msg-id 200803111945.m2BJj2w09898@momjian.us
Whole thread Raw
In response to Re: What is the maximum encoding-conversion growth rate, anyway?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Added to TODO:

* Change memory allocation for multi-byte functions so memory is allocated inside conversion functions
 Currently we preallocate memory based on worst-case usage.


---------------------------------------------------------------------------

Tom Lane wrote:
> Tatsuo Ishii <ishii@postgresql.org> writes:
> > Thinking more, it striked me that users can define arbitarily growing
> > rate by using CFREATE CONVERSION. So it seems we need functionality to
> > define the growing rate anyway.
> 
> Seems to me that would be an argument for moving the palloc inside the
> conversion functions, as I suggested before.
> 
> In practice though, I find it hard to imagine a pair of encodings for
> which the growth rate is more than 3x.  You'd need something that
> translates a single-byte character into 4 or more bytes (pretty
> unlikely, especially considering we require all these encodings to be
> ASCII supersets); or something that translates a 2-byte character into
> more than 6 bytes.
> 
>             regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Command tags in create/drop scripts
Next
From: Bruce Momjian
Date:
Subject: Re: Fractions in GUC variables