Re: State of Beta 2

From: Network Administrator <netadmin(at)vcsn(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PgSQL General ML <pgsql-general(at)postgresql(dot)org>
Subject: Re: State of Beta 2
Date: 2003-09-15 03:56:52
Message-ID: 1063598212.3f653884b6b3c@webmail.vcsn.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Network Administrator <netadmin(at)vcsn(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message elein 2003-09-15 03:57:55 [elein@varlena.com: Re: is General Bits Issue # 43 correct?]
Previous Message Tom Lane 2003-09-15 03:26:57 Re: case-insensitive database