Обсуждение: Patch for 'Not to stuff everything as files in a single directory, hash dirs'

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
----------------------------------

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,
Pennsylvania19026
 

> 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,
Pennsylvania19026
 

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,
Pennsylvania19026