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@krogh.cc
Jabber ID: jesper@jabbernet.dk