Re: Re: Large Objects

From: "Edward Q(dot) Bridges" <ed(dot)bridges(at)buzznik(dot)com>
To: "Alessio Bragadini" <alessio(at)albourne(dot)com>, "Neil Conway" <nconway(at)klamath(dot)dyndns(dot)org>
Cc: "PostgreSQL general mailing list" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Re: Large Objects
Date: 2000-09-21 14:54:52
Message-ID: 200009211457.e8LEv2s05869@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


in effect, this turns the filesystem into a "poor-mans" balanced tree.
the rdbms gives you a "rich-mans" balanced tree, but along with the
overhead of the rdbms.

cheers
--e--

On Thu, 21 Sep 2000 15:20:39 +0300, Alessio Bragadini wrote:

> Neil Conway wrote:
>
> > > a BLOB. Conversely, Unix filesystems store directories as unsorted
> > > lists, which are a lot slower to search than the database's
> > > structured indexes.
>
> > Wow, can anyone confirm this (with Postgres preferrably)? In talking
> > with some developers at my old job, they all agreed that storing large
> > pieces of data (1k < x < 16K) was significantly faster on the FS than
>
> I believe he's talking about storing all files in the same directory,
> which is simply The Wrong Way for a number of reasons. While saving a
> large number of external files, we use a sub-dir structure in the form
> /data/f4/d3/12/myfile.bin in order to spread the number of files in a
> tree pseudorandomly. This is the same approach used by the Squid
> webcache.
>
> --
> Alessio F. Bragadini alessio(at)albourne(dot)com
> APL Financial Services http://village.albourne.com
> Nicosia, Cyprus phone: +357-2-755750
>
> "It is more complicated than you think"
> -- The Eighth Networking Truth from RFC 1925
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Edward Q. Bridges 2000-09-21 15:06:48 Re: Re: sequences
Previous Message Poul L. Christiansen 2000-09-21 14:18:12 Re: replication