On Tue, 13 Apr 2004 12:56:09 +0200, Holger Klawitter wrote:
Oh please. Reiser is as unstable as postgres is slow - in other words,
both have to suffer prejudice which used to be true lng ago. ;-)
True.
In cases of large directories ext2/3 perform extremely bad (as in the
original post)
Your code is retrieving the file from the file system. It doesn't have
to be accessible from the web server at all. Our current design uses a
JDBC connection to the database for the metadata (digital
signature,path,name,file type, etc..) and a SOAP call to the same server
(but doesn't have to be)
On Wed, Apr 14, 2004 at 10:15:51PM +0900, Alex wrote:
Hi,
is the file system approach really easier and faster? What if you need
to protect the image data e.g. you dont want users just to just dowload
the pictures directly from your website?
It can be much faster, if implemented correctly,
Hello,
I am working on web portal. There are some ads. We have about 200 000
ads. Every ad have own directory called ID, where is 5 subdirectories
with various sizes of 5 images.
Filesystem is too slow. But I don't know, if I store these images into
postgres, performace will grow.
Second question
Hello,
Filesystem is too slow. But I don't know, if I store these images into
postgres, performace will grow.
but postres also stores its data on the filesystem.
maybe take a better FS like XFS (xfs is very nice and performes good),
imho other filesystems like reiser have some version-problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
imho other filesystems like reiser have some version-problems ;)
Oh please. Reiser is as unstable as postgres is slow - in other words, both
have to suffer prejudice which used to be true lng ago. ;-)
In cases of large directories ext2/3
On Tue, 2004-04-13 at 01:44, Michal Hlavac wrote:
Hello,
I am working on web portal. There are some ads. We have about 200 000
ads. Every ad have own directory called ID, where is 5 subdirectories
with various sizes of 5 images.
Filesystem is too slow. But I don't know, if I store these
There has got to be some sort of standard way to do this. We have the
same problem where I work. Terabytes of images, but the question is
still sort of around BLOBs or Files? Our final decision was to use the
file system. We found that you didn't really gain anything by storing
the images in the
Hello,
No standard way that I know of :). We tend to use BLOBS because we can
have associated tables
with metadata about the images that can be searched etc Of course
you could that with the filesystem
as well but we find blobs easier.
I will say we tend to use BLOBS or Bytea.
J
Jeremiah
On Apr 13, 2004, at 9:40 AM, Jeremiah Jahn wrote:
There has got to be some sort of standard way to do this. We have the
same problem where I work. Terabytes of images, but the question is
still sort of around BLOBs or Files? Our final decision was to use
the
file system. We found that you didn't
I tried the bytea types, but the parsing done by the system on insert
etc. was so bad that it made it usable for me. Our solution is to keep
all of the metadata in the db plus an id and then a web service that
gets the image from the FS.
On Tue, 2004-04-13 at 09:05, Joshua D. Drake wrote:
11 matches
Mail list logo
