Re: [HACKERS] extending postgres buffer/query limits - Mailing list pgsql-hackers

From dj@pelf.harvard.edu (Diab Jerius)
Subject Re: [HACKERS] extending postgres buffer/query limits
Date
Msg-id d9dbe183139c1efc5d8721913e2ede6a
Whole thread Raw
In response to [HACKERS] extending postgres buffer/query limits  (dj@pelf.harvard.edu (Diab Jerius))
List pgsql-hackers
- ---------  Received message begins Here  ---------

> From: Bruce Momjian <maillist@candle.pha.pa.us>
> Message-Id: <199706201630.MAA03762@candle.pha.pa.us>
> Subject: Re: [HACKERS] extending postgres buffer/query limits
> To: djerius@cfa.harvard.edu
> Date: Fri, 20 Jun 1997 12:30:19 -0400 (EDT)

[deletia]
> >
> > Can someone point me to where I should start looking in order to relieve
> > the buffer limitations in postgres?  I can't make the table any narrower.
>
> I find this hard to believe.
>

Well, I won't quibble over data base design here.  The table is completely
normalized, or whatever the correct terminology is.  There's but one key and
several hundred dependent fields (it's the output of a X-ray line fit,
which does indeed have that many parameters).  Obviously I can split the
table up, dump the bits, and rejoin them, but that's not the point.

The point is that it is possible to create tables which pg_dump can't handle.
This shouldn't happen.  This may be fixed in 6.1, but I can't test that until I
can move my data over, which now promises to be a real pain.


- -------------
Diab Jerius                       Harvard-Smithsonian Center for Astrophysics
                                  60 Garden St, MS 70, Cambridge MA 02138 USA
djerius@cfa.harvard.edu           vox: 617 496 7575         fax: 617 495 7356

------------------------------

End of hackers-digest V1 #393
*****************************

pgsql-hackers by date:

Previous
From: ycourties@internet.ubisoft.fr (Yann Courties)
Date:
Subject: RE: [HACKERS] TR: Problems with Large Objects !!
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] 6.1 jumbo patch?