Re: Are there performance advantages in storing bulky field in separate table?
От | Tom Lane |
---|---|
Тема | Re: Are there performance advantages in storing bulky field in separate table? |
Дата | |
Msg-id | 12928.1239205663@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Are there performance advantages in storing bulky field in separate table? (Ian Mayo <ianmayo@tesco.net>) |
Ответы |
Re: Are there performance advantages in storing bulky field
in separate table?
Re: Are there performance advantages in storing bulky field in separate table? |
Список | pgsql-general |
Ian Mayo <ianmayo@tesco.net> writes: > I've got a fairly straightforward table that's similar to a blog table > (entryId, date, title, author, etc). There is, however, the > requirement to allow a single, fairly bulky binary attachment to > around 1% of the rows. > There will be a few million rows, and I value efficient searches by > date, title, and author. > Would there be a performance advantage in storing the attachment in a > separate table - linked by entryId foreign key? No. You'd basically be manually reinventing the TOAST mechanism; or the large object mechanism, if you choose to store the blob as a large object rather than a plain bytea field. Either way, it won't physically be in the same table as the main row data. If you're curious, this goes into some of the gory details: http://www.postgresql.org/docs/8.3/static/storage-toast.html regards, tom lane
В списке pgsql-general по дате отправления: