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
>
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 |