Обсуждение: 6.4.x

I apologize.  pgsql-questions has disappeared? (out of the loop, I am)

> 
> Hello,
> 
> My questions are:
>     (1) does 6.4 offer speed improvements over 6.3.2?
>     (2) does 6.4 offer stability improvements over 6.3.2?
>     (3) does 6.4 support query lengths > 8192, or data blocks > 8192 (other than large objects)?
>     
> If anyone knows, I thank you.
> 
> Eddie
> abrams@philos.umass.edu
> 

On Wed, 25 Nov 1998, Integration wrote:

> I apologize.  pgsql-questions has disappeared? (out of the loop, I am)
Disappeared about 6 months ago or so...

> 
> > 
> > Hello,
> > 
> > My questions are:
> >     (1) does 6.4 offer speed improvements over 6.3.2?
> >     (2) does 6.4 offer stability improvements over 6.3.2?
> >     (3) does 6.4 support query lengths > 8192, or data blocks > 8192 (other than large objects)?
> >     
> > If anyone knows, I thank you.
> > 
> > Eddie
> > abrams@philos.umass.edu
> > 
> 

Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

On Wed, 25 Nov 1998, Integration wrote:

> I apologize.  pgsql-questions has disappeared? (out of the loop, I am)
> 
> > 
> > Hello,
> > 
> > My questions are:
> >     (1) does 6.4 offer speed improvements over 6.3.2?
Yes...

> >     (2) does 6.4 offer stability improvements over 6.3.2?
Yes...

> > (3) does 6.4 support query lengths > 8192, or data blocks > 8192
> (other than large objects)?
Not yet, but Bruce has/had some ideas for v6.5 for doing this
using a row-spanning method...theory sounded great :)


Marc G. Fournier                                
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 

> > (1) does 6.4 offer speed improvements over 6.3.2?

Yes, though probably not as noticable as for the previous release.

> > (2) does 6.4 offer stability improvements over 6.3.2?

Yes.

> > (3) does 6.4 support query lengths > 8192, or data blocks > 8192 
> > (other than large objects)?

Sometime in the past Darren K. worked to parameterize this limit. I
believe that this is in the code, but you will have to bump up the limit
and see if it works for you. The downside to having larger data blocks
is that the database size will be somewhat larger.
                      - Tom

>>>> (2) does 6.4 offer stability improvements over 6.3.2?

> Yes.

FWIW, 6.4 is noticeably more stable than 6.3.2 in my company's
application involving concurrent users of a shared database.
We have not seen a backend crash or data corruption since installing
a pre-alpha-6.4 server in mid-September.  We had several such problems
in the preceding couple of months with 6.3.2.


>>>> (3) does 6.4 support query lengths > 8192, or data blocks > 8192 
>>>> (other than large objects)?

> Sometime in the past Darren K. worked to parameterize this limit.

There has been some discussion of allowing tuples to span multiple
disk blocks, which would remove the problem entirely, but it hasn't
happened yet.  Maybe for 6.5?

The limit on the textual length of a query is an unrelated quantity
that by coincidence has the same value.  (Well, maybe not total
coincidence... probably someone wanted to be sure they could INSERT
an 8K text string... but the code doesn't know there's a connection.)
I am planning to modify libpq and the backend to eliminate fixed-size
query text buffers, so this limit should go away for 6.5.
        regards, tom lane

Tom Lane wrote:
> 
> >>>> (3) does 6.4 support query lengths > 8192, or data blocks > 8192
> >>>> (other than large objects)?
> 
> > Sometime in the past Darren K. worked to parameterize this limit.
> 
> There has been some discussion of allowing tuples to span multiple
> disk blocks, which would remove the problem entirely, but it hasn't
> happened yet.  Maybe for 6.5?

Right now I'm rewriting HeapTuple structure and functions - for
multi-version concurrency control (MVCC). New HeapTuple:

typedef struct HeapTupleData
{    uint32              t_len;      /* length of *t_data */   ItemPointerData     t_self;     /* SelfItemPointer */
HeapTupleHeader    t_data;     /* */   ^^^^^^^^^^^^^^^^^^^^^^^^^^   this is what known as HeapTuple in < 6.5
 
} HeapTupleData;

I assume that one, who would like implement blocks spanning, 
will add something to this new structure. 
I need in ~ one week, please wait.

Vadim

> Tom Lane wrote:
> > 
> > >>>> (3) does 6.4 support query lengths > 8192, or data blocks > 8192
> > >>>> (other than large objects)?
> > 
> > > Sometime in the past Darren K. worked to parameterize this limit.
> > 
> > There has been some discussion of allowing tuples to span multiple
> > disk blocks, which would remove the problem entirely, but it hasn't
> > happened yet.  Maybe for 6.5?
> 
> Right now I'm rewriting HeapTuple structure and functions - for
> multi-version concurrency control (MVCC). New HeapTuple:
> 
> typedef struct HeapTupleData
> { 
>     uint32              t_len;      /* length of *t_data */
>     ItemPointerData     t_self;     /* SelfItemPointer */
>     HeapTupleHeader     t_data;     /* */
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>     this is what known as HeapTuple in < 6.5
> } HeapTupleData;
> 
> I assume that one, who would like implement blocks spanning, 
> will add something to this new structure. 
> I need in ~ one week, please wait.

Block spanning was only an idea.  No idea how to code it.  Yet.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@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