Re: BLOB support

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Pavel Golub <pavel(at)gf(dot)microolap(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BLOB support
Date: 2011-06-02 13:49:20
Message-ID: BANLkTik_vdA0f0TqwJmFter1Vvs21AeDmw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/6/2 Pavel Golub <pavel(at)microolap(dot)com>:
> Hello, Pavel.
>
> You wrote:
>
> PS> 2011/6/2 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>> On ons, 2011-06-01 at 22:00 +0200, Radosław Smogura wrote:
>>>> I partialy implemented following missing LOBs types. Requirement for this was
>>>> to give ability to create (B/C)LOB columns and add casting functionality e.g.
>>>> SET my_clob = 'My long text'.
>>>>
>>>> Idea is as follow:
>>>> 0. Blob is two state object: 1st in memory contains just bytea, serialized
>>>> contains Oid of large object.
>>>> 1. Each type has additional boolean haslobs, which is set recursivly.
>>>> 2. Relation has same bool haslobs (used to speed up tables without LOBs)
>>>> 3. When data are inserted/updated then "special" function is called and tuple
>>>> is modified in this way all LOBs are serialized to (old) LOB table and just
>>>> Oid is stored.
>>>> 4. When removed LOB is removed from (old) LOB table.
>>>
>>> Superficially, this looks like a reimplementation of TOAST.  What
>>> functionality exactly do you envision that the BLOB and CLOB types would
>>> need to have that would warrant treating them different from, say, bytea
>>> and text?
>>>
>
> PS> a streaming for bytea could be nice. A very large bytea are limited by
> PS> query size - processing long query needs too RAM,
>
> LO (oid) solves this, doesn't it?

partially

There is a few disadvantages LO against bytea, so there are requests
for "smarter" API for bytea.

Significant problem is different implementation of LO for people who
have to port application to PostgreSQL from Oracle, DB2. There are
some JDBC issues too.

For me - main disadvantage of LO in one space for all. Bytea removes
this disadvantage, but it is slower for lengths > 20 MB. It could be
really very practical have a possibility insert some large fields in
second NON SQL stream. Same situation is when large bytea is read.

Pavel

>
> PS> Pavel
>
>>>
>>>
>>> --
>>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-hackers
>>>
>
>
>
>
> --
> With best wishes,
>  Pavel                          mailto:pavel(at)gf(dot)microolap(dot)com
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-02 13:59:42 Re: BLOB support
Previous Message Robert Haas 2011-06-02 13:46:46 Re: Re: patch review : Add ability to constrain backend temporary file space