Tom Lane <tgl@sss.pgh.pa.us> Friday 03 of June 2011 16:44:13
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Excerpts from RadosÅaw Smogura's message of jue jun 02 15:26:29 -0400
2011:
> >> So do I understand good should We think about create bettered TOAST to
> >> support larger values then 30-bit length? I like this much more,
> >
> > Good :-)
> >
> > (BTW while it'd be good to have longer-than-30 bit length words for
> > varlena, I'm not sure we have room for that.)
>
> You wouldn't want to push such values around as whole values anyway.
> Possibly what would work here is a variant form of TOAST pointer for
> which we'd simply throw error if you tried to fetch the entire value
> at once.
>
> regards, tom lane
Ok, now it's more clear about this, what You have talked about, but I still
need to pass constant ID to client.
Actually, this variant must be passed to client.
Form other side, as BLOB may be created before statement invoke or if it's
called. This will require to create tempolary BLOBs, and introducing v3.1
protocol, which will allow to stream values greater then 4GB, by passing -2
size in length fields, and introducing stream_in/out in pg_type (this is from
my concept of streaming protocol).
So I think better will be to introduce 1st streaming protocol, as it is on top
LOBs. I will send thread for this in a moment.
>> Why? The tuples are not going away due to MVCC anyway.
Vaccum / autovacumm + no lock may be enaugh, I think. Constant ID is required.
Regards,
Radek
