Neil Conway <[EMAIL PROTECTED]> writes:
> On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
>> The code churn to do this is going to be quite significant
> Why do you say that? Although the original patch posted to implement
> this was incomplete, it certainly wasn't very large.
IIRC, the o
Bruce Momjian wrote:
> I assume the conclusion from this email thread is that though the idea
> is interesting, the complexity added would not be worth the saving of a
> few bytes.
I have same understanding about it. Besides the complexity,
there is trade-off between cpu and i/o resources.
Also,
On Wed, 2006-06-14 at 16:56 -0400, Bruce Momjian wrote:
> The code churn to do this is going to be quite significant
Why do you say that? Although the original patch posted to implement
this was incomplete, it certainly wasn't very large.
-Neil
---(end of broadcast)
The code churn to do this is going to be quite significant, as well a
performance-wise hit perhaps, so it has to be a big win.
---
Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 04:21:34PM -0400, Bruce Momjian wrote:
> > Jim
On Wed, Jun 14, 2006 at 04:21:34PM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> > >
> > > I assume the conclusion from this email thread is that though the idea
> > > is interesting, the complexity added would not be worth t
Jim C. Nasby wrote:
> On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
> >
> > I assume the conclusion from this email thread is that though the idea
> > is interesting, the complexity added would not be worth the saving of a
> > few bytes.
>
> Anyone do any testing?
>
> I'm also
On Wed, Jun 14, 2006 at 02:53:10PM -0400, Bruce Momjian wrote:
>
> I assume the conclusion from this email thread is that though the idea
> is interesting, the complexity added would not be worth the saving of a
> few bytes.
Anyone do any testing?
I'm also wondering if this would be useful to a
I assume the conclusion from this email thread is that though the idea
is interesting, the complexity added would not be worth the saving of a
few bytes.
---
ITAGAKI Takahiro wrote:
> Hi Hackers,
>
> PostgreSQL can treat va
Manfred Koizar <[EMAIL PROTECTED]> writes:
> I.e. drop the flags for very short strings.
I don't think the interaction of this idea with TOAST has been thought
through very carefully. Some points to consider:
* If the 'e' (external) bit is set, the actual length is 20 or so bytes.
Always. There
On Thu, 08 Sep 2005 18:02:44 +0900, ITAGAKI Takahiro
<[EMAIL PROTECTED]> wrote:
+ * The length of varlena2 is encoded as follows:
+ *
+ * | First| Trailing | Total | Max |
+ * | byte | bytes| bits | length |
+ * +--+--+---+-+
+ * | 0*** |
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> If the new text type wins VARCHAR in many respects,
> I'd like to propose to replace VARCHAR with it.
This idea would impose fairly significant overhead in a number of
places, for instance locating field starts within a tuple. It didn't
appear to me
Josh Berkus wrote:
> Wouldn't this require creating, for example, a SHORTTEXT type?
Yes, new types are required. There are no binary compatibility between
them and existing variable length types (text, bytea, etc.).
But 'SHORTTEXT' is not a proper name for them. They can represent
long texts tho
On 9/8/05 9:53 AM, "Josh Berkus" wrote:
>
> Hmmm. Seems like these would be different data types from the standard ones
> we deal with. I can see the value for data warehousing, for example.
>
> Wouldn't this require creating, for example, a SHORTTEXT type? Or were you
> planning this to hand
ITAGAKI Takahiro wrote:
# select * from pgstattuple('txttbl');
-[ RECORD 1 ]--+--
table_len | 8192
tuple_count| 1
tuple_len | 57<-- 28 + (5+3) + (5+3) + (5+3) + (5)
...
# select * from pgstattuple('strtbl');
-[ RECORD 1 ]--+--
table_len |
On Thu, 2005-09-08 at 09:53 -0700, Josh Berkus wrote:
> Takahiro,
>
> > PostgreSQL can treat variable-length data flexibly, but therefore
> > it consumes more spaces if we store short data. Headers of
> > variable-length types use 4 bytes regardless of the data length.
> >
> > My idea is to change
Takahiro,
> PostgreSQL can treat variable-length data flexibly, but therefore
> it consumes more spaces if we store short data. Headers of
> variable-length types use 4 bytes regardless of the data length.
>
> My idea is to change the header itself to variable-length.
> In order to reduce the size
Hi Hackers,
PostgreSQL can treat variable-length data flexibly, but therefore
it consumes more spaces if we store short data. Headers of
variable-length types use 4 bytes regardless of the data length.
My idea is to change the header itself to variable-length.
In order to reduce the size of shor
17 matches
Mail list logo
