Re: State of Beta 2 - Mailing list pgsql-general

From Network Administrator
Subject Re: State of Beta 2
Date
Msg-id 1063598212.3f653884b6b3c@webmail.vcsn.com
Whole thread Raw
In response to Re: State of Beta 2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: State of Beta 2
List pgsql-general
Quoting Tom Lane <tgl@sss.pgh.pa.us>:

> Network Administrator <netadmin@vcsn.com> writes:
> > The abstraction I am talking about would be a logical layer that would
> handle
> > disk I/O including the format of that data (lets call this the ADH).
>
> This sounds good in the abstract, but I don't see how you would define
> such a layer in a way that was both thin and able to cope with large
> changes in representation.  In a very real sense, "handle disk I/O
> including the format of the data" describes the entire backend.  To
> create an abstraction layer that will actually give any traction for
> maintenance, you'd have to find a way to slice it much more narrowly
> than that.

*nod* I thought that would probably be the case.  The "thickness" of that layer
would be directly related to how the backend was sliced.  However it seems to me
that right now that this might not be possible while the backend is changing
between major releases.  Perhaps once that doesn't fluxate as much it might be
feasible to create these layer so that it is not too fat.

Maybe the goal is too aggressive.  To ask (hopefully) a simpler question.  Would
it be possible to at compile time choose the on disk representation?  I'm not
sure but I think that might reduce the complexity since the abstraction would
only exist before the application is built.  Once compiled there would be no
ambiguity in what representation is chosen.

> Even if the approach can be made to work, defining such a layer and then
> revising all the existing code to go through it would be a huge amount
> of work.
>
> Ultimately there's no substitute for hard work :-(
>
>             regards, tom lane

True, which is why I've never been bothered about going through a process to
maintain my database's integrity and performance.  However, over time, that
across my entire client base I will eventually reach a point where I will need
to do an "in place" upgrade or at least limit database downtime to a 60 minute
window- or less.



--
Keith C. Perry
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

pgsql-general by date:

Previous
From: "Muhyiddin A.M Hayat"
Date:
Subject: The NT services Cygwin PostgreSQL installatio
Next
From: elein
Date:
Subject: [elein@varlena.com: Re: is General Bits Issue # 43 correct?]