Re: Storing binary data.
От | Jesper Krogh |
---|---|
Тема | Re: Storing binary data. |
Дата | |
Msg-id | cfdhhd$ft2$1@sea.gmane.org обсуждение исходный текст |
Ответ на | Storing binary data. (Jesper Krogh <jesper@krogh.cc>) |
Ответы |
Re: Storing binary data.
|
Список | 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@krogh.cc Jabber ID: jesper@jabbernet.dk
В списке pgsql-performance по дате отправления: