From: | Jesper Krogh <jesper(at)krogh(dot)cc> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Storing binary data. |
Date: | 2004-08-11 16:29:33 |
Message-ID: | cfdhhd$ft2$1@sea.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I gmane.comp.db.postgresql.performance, skrev Shridhar Daithankar:
> On Wednesday 11 Aug 2004 7:59 pm, Jesper Krogh wrote:
> > The "common" solution, I guess would be to store them in the filesystem
> > instead, but I like to have them just in the database it is nice clean
> > database and application design and if I can get PostgreSQL to "not
> > cache" them then it should be excactly as fast i assume.
>
> You can normalize them so that a table contains an id and a bytea column only.
> Te main table will contain all the other attributes and a mapping id. That
> way you will have only the main table cached.
>
> You don't have to go to filesystem for this, I hope.
Further benchmarking.
I tried to create a table with the excact same attributes but without
the binary attribute. It didn't change anything, so my idea that it
should be the binary-stuff that sloved it down was wrong.
I have a timestamp column in the table that I sort on. Data is ordered
over the last 4 years and I select based on a timerange, I cannot make
the query-planner use the index on the timestamp by itself but if I "set
enable_seqscan = false" the query time drops by 1/3 (from 1.200 msec to
about 400 msec).
I cannot figure out why the query-planner chooses wrong.
NB: It's postgresql 7.4.3
--
./Jesper Krogh, jesper(at)krogh(dot)cc
Jabber ID: jesper(at)jabbernet(dot)dk
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-08-11 16:37:10 | Re: fsync vs open_sync |
Previous Message | Bruno Wolff III | 2004-08-11 16:27:01 | Re: How to know which queries are to be optimised? |