Обсуждение: Re: [INTERFACES] Large objects, why not use the filesystem?

----- Original Message -----
From: Thomas G. Lockhart <lockhart@alumni.caltech.edu>
To: Gregory W Burnham <gburnham@sfu.ca>
Cc: <pgsql-interfaces@postgreSQL.org>
Sent: Monday, February 01, 1999 5:26 AM
Subject: Re: [INTERFACES] Large objects, why not use the filesystem?


>> Ok, I've seen all the xinv* files, I understand that.  But what
>> if the benefit of using large objects over files?  If there isn't
>> superior performance then why do it?
>
>To provide a consistant access interface in a client-server environment.
>Managing one interface is usually easier than managing several (e.g.
>postgres, html, ftp, ...) to support a single app.

Right, but I'm storing html and gif in my blobs and just
writing them out to stdout.  Why shouldn't I just store
the file names and put the files right on the server?

>I would expect the performance of LOs to be somewhat worse than direct
>file system access to the same data, for a variety of reasons. But for
>many applications that performance difference is not a critical issue.

To quote a friend of mine, "Efficiency is an issue only when
inefficiency is a problem."  But still, you want to be as
efficient as possible, right?  In retrospec, it would have
been more efficient to store all four digits of the year, right?

Gregory W Burnham
Software Engineer
Excite Labs
Faculty Of Education
Simon Fraser University
Vancouver, BC, V5A 1S6
604 291 3615 (ph)
604 291 5679 (fx)

At 15:28 +0200 on 01/02/1999, Gregory W Burnham wrote:


> Right, but I'm storing html and gif in my blobs and just
> writing them out to stdout.  Why shouldn't I just store
> the file names and put the files right on the server?

No reason at all. If it works for your application, then Buy Nike... oops,
I meant "Just Do It". There are pros and cons for Blobs. If the pros don't
hold for you, don't use Blobs.

> To quote a friend of mine, "Efficiency is an issue only when
> inefficiency is a problem."  But still, you want to be as
> efficient as possible, right?  In retrospec, it would have
> been more efficient to store all four digits of the year, right?

Actually, it would simply have postponed the problem to a later date...

Herouth

--
Herouth Maoz, Internet developer.
Open University of Israel - Telem project
http://telem.openu.ac.il/~herutma

> > To quote a friend of mine, "Efficiency is an issue only when
> > inefficiency is a problem."  But still, you want to be as
> > efficient as possible, right?  In retrospec, it would have
> > been more efficient to store all four digits of the year, right?
> Actually, it would simply have postponed the problem to a later
> date...

*rolf* Good point. And I'd like to mention that Postgres *is* Y10K
compliant, for those needing to plan ahead :)

                     - Tom