Patch for 'Not to stuff everything as files in a single directory, hash dirs'

Seems the whole large object per file is going away in 7.1. Can someone
confirm this?

Hello all,

I did small patch for subj. I am sure that it is not perfect, but it works for me.
I will continue its testing. This is my first patch to pgsql. If you will find some
obvious mistakes, do not flame, just show the right way.

If you have further suggestion/ideas, do not hesistate to contact me.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

[ Attachment, skipping... ]

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

I did small patch for subj. I am sure that it is not perfect, but it works for me.
I will continue its testing. This is my first patch to pgsql. If you will find some
obvious mistakes, do not flame, just show the right way.

If you have further suggestion/ideas, do not hesistate to contact me.

Forget about this. Better patch posted to pgsql-patches.

--
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Bruce Momjian wrote:

Seems the whole large object per file is going away in 7.1. Can someone
confirm this?

Not the whole one in 7.1.

The TOAST stuff will lower the need for large objects alot,
but we already discovered the fact that it isn't a real
answer to LARGE objects.

First of all, the entire datum must be properly quoted to fit
into a querystring. Therefore the client needs to have the
original datum, the qouted copy, the querystring it built.
Then the querystring is sent to the backend, parsed (where a
CONST node is built from it), copied into a tuple to be split
up into TOAST items.

So on a central system, where client and DB are both running,
we have 6 copies of the object in memory! Not that optimal.

For 7.2 I'll work on real CLOB and BLOB data types. Requires
some more thinking though.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Bruce Momjian wrote:

Seems the whole large object per file is going away in 7.1. Can someone
confirm this?

Not the whole one in 7.1.

The TOAST stuff will lower the need for large objects alot,
but we already discovered the fact that it isn't a real
answer to LARGE objects.

First of all, the entire datum must be properly quoted to fit
into a querystring. Therefore the client needs to have the
original datum, the qouted copy, the querystring it built.
Then the querystring is sent to the backend, parsed (where a
CONST node is built from it), copied into a tuple to be split
up into TOAST items.

So on a central system, where client and DB are both running,
we have 6 copies of the object in memory! Not that optimal.

For 7.2 I'll work on real CLOB and BLOB data types. Requires
some more thinking though.

I thought we would keep the existing large object interface, but allow
storage of large object data directly in fields using TOAST.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

My idea was to implement the large object API on top of TOAST.

Bruce Momjian wrote:

Seems the whole large object per file is going away in 7.1. Can someone
confirm this?

Not the whole one in 7.1.

The TOAST stuff will lower the need for large objects alot,
but we already discovered the fact that it isn't a real
answer to LARGE objects.

First of all, the entire datum must be properly quoted to fit
into a querystring. Therefore the client needs to have the
original datum, the qouted copy, the querystring it built.
Then the querystring is sent to the backend, parsed (where a
CONST node is built from it), copied into a tuple to be split
up into TOAST items.

So on a central system, where client and DB are both running,
we have 6 copies of the object in memory! Not that optimal.

For 7.2 I'll work on real CLOB and BLOB data types. Requires
some more thinking though.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026