Re: Extending varlena

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extending varlena
Date: 2008-08-19 08:12:10
Message-ID: 48AA805A.407@hagander.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Mon, 2008-08-18 at 16:22 -0400, Tom Lane wrote:
>> David Fetter <david(at)fetter(dot)org> writes:
>>> What would need to happen for the next jump up from where varlena is
>>> now, to 8 bytes?
>> Dealing with upwards-of-4GB blobs as single Datums isn't remotely sane,
>> and won't become so in the near (or even medium) future. So I don't
>> see the point of doing all the work that would be involved in making
>> this go.
>>
>> What would make more sense is to redesign the large-object stuff to be
>> somewhat modern and featureful, and provide stream-access APIs (think
>> lo_read, lo_seek, etc) that allow offsets wider than 32 bits. The main
>> things I think we'd need to consider besides just the access API are
>>
>> - permissions features (more than "none" anyway)
>> - better management of orphaned objects (obsoleting vacuumlo)
>> - support > 16TB of large objects (maybe partition pg_largeobject?)
>> - dump and restore probably need improvement to be practical for such
>> large data volumes
>
> Sounds like a good list.
>
> Probably also using a separate Sequence to allocate numbers rather than
> using up all the Oids on LOs would be a good plan.

The ability to partition the large object store would not suck either...
For backup/recovery purposes mainly.

//Magnus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Asko Oja 2008-08-19 08:27:09 Re: Patch: plan invalidation vs stored procedures
Previous Message Magnus Hagander 2008-08-19 08:11:09 Re: Extending varlena