By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,792 Members | 1,489 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,792 IT Pros & Developers. It's quick & easy.

BLOB problem

P: n/a
Hi,

I've encountered a problem with a PostgreSQL database. I made a image
management system which stores images in a database from a PHP script. I
upload te file using pg_lo_import() (PHP function). Everything works
fine, fast, and I was really glad with it, till I found out that my
database is rapadly growing. With only 20 images the database has a size
of 65 MB !!!

Does anybody know where this come from ? I know I don't give a lot of
information, if you want more, ask for it. But I don't want to send
unreadable posts ;-)

Grtz

Nov 22 '05 #1
Share this Question
Share on Google+
5 Replies

P: n/a
Rens Admiraal <po**********@etraned.nl> writes:
upload te file using pg_lo_import() (PHP function). Everything works
fine, fast, and I was really glad with it, till I found out that my
database is rapadly growing. With only 20 images the database has a size
of 65 MB !!!


Hard to tell much from that statement. I'd suggest looking into the
$PGDATA directory tree to find out which files are taking up the bulk of
the space --- with that info we can give you some advice.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #2

P: n/a
On Tue, 3 Feb 2004, Tom Lane wrote:
Rens Admiraal <po**********@etraned.nl> writes:
upload te file using pg_lo_import() (PHP function). Everything works
fine, fast, and I was really glad with it, till I found out that my
database is rapadly growing. With only 20 images the database has a size
of 65 MB !!!


Hard to tell much from that statement. I'd suggest looking into the
$PGDATA directory tree to find out which files are taking up the bulk of
the space --- with that info we can give you some advice.


Also note, Rens, that a freshly initdb'd database ain't tiny to start
with. template0 and template1 take up about 4 megs each, and each fresh,
"empty" database another 4 or so. This is on my workstation. Plus, each
transaction log is 16 megs or larger if you've reconfigured for more
checkpoints.

So, if you have two empty databases, plus two transactions logs, that'll
add up to 4*4 meg + 2*16 meg for a total of 3*16 or 48 Meg. Before
importing any data.


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 22 '05 #3

P: n/a
Hello
I've encountered a problem with a PostgreSQL database


Are you sure that the problem is with PostgreSQL?

I was testing pg_lo_import() with PHP 4.3.x and found it buggy. I had
the opposite problem: only a few bytes from a large object were stored
in the database. Then I downgraded to PHP 4.2 and the same script
works well on the same database.

Regards
Conni
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 22 '05 #4

P: n/a
On Wed, 4 Feb 2004, Cornelia Boenigk wrote:
Hello
I've encountered a problem with a PostgreSQL database


Are you sure that the problem is with PostgreSQL?

I was testing pg_lo_import() with PHP 4.3.x and found it buggy. I had
the opposite problem: only a few bytes from a large object were stored
in the database. Then I downgraded to PHP 4.2 and the same script
works well on the same database.


I never had any problems with LOs on a php 4.3.x <--> Postrgresql system I was
working on last year. There must have been something else happening that isn't
attributable to use of LOs.
--
Nigel J. Andrews
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 22 '05 #5

P: n/a
I agree with Nigel, and I'll take a guess as to why you experienced this,
Conni. If Postgres was upgraded after PHP 4.3.x was installed and PHP
wasn't recompiled, PHP was working with an outdated Postgres client. When
you downgraded, you're recompile used the new client. You could have gotten
the same result just by recompiling the same version of PHP.
-----Original Message-----
From: pg*****************@postgresql.org
[mailto:pg*****************@postgresql.org]On Behalf Of Nigel J. Andrews
Sent: Wednesday, February 04, 2004 2:23 AM
To: Cornelia Boenigk
Cc: scott.marlowe; Tom Lane; Rens Admiraal; pg***********@postgresql.org
Subject: Re: [GENERAL] BLOB problem
On Wed, 4 Feb 2004, Cornelia Boenigk wrote:
Hello
I've encountered a problem with a PostgreSQL database


Are you sure that the problem is with PostgreSQL?

I was testing pg_lo_import() with PHP 4.3.x and found it buggy. I had
the opposite problem: only a few bytes from a large object were stored
in the database. Then I downgraded to PHP 4.2 and the same script
works well on the same database.


I never had any problems with LOs on a php 4.3.x <--> Postrgresql
system I was
working on last year. There must have been something else
happening that isn't
attributable to use of LOs.
--
Nigel J. Andrews


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 22 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.