Re: Index on (fixed size) bytea value
От
Les
Тема
Re: Index on (fixed size) bytea value
Дата
Msg-id
CAKXe9UA9gmFH8AeY6_LLiWDt=Z648c+3Wqb3uY7B455hZEAT_g@mail.gmail.com
Ответ на
Re: Index on (fixed size) bytea value (David G. Johnston)
Список
Дерево обсуждения
Index on (fixed size) bytea value Les <nagylzs@gmail.com>
Re: Index on (fixed size) bytea value "David G. Johnston" <david.g.johnston@gmail.com>
Re: Index on (fixed size) bytea value Les <nagylzs@gmail.com>
Re: Index on (fixed size) bytea value Laurenz Albe <laurenz.albe@cybertec.at>
Re: Index on (fixed size) bytea value Les <nagylzs@gmail.com>
David G. Johnston <david.g.johnston@gmail.com> ezt írta (időpont: 2023. jún. 19., H, 22:30):
On Mon, Jun 19, 2023 at 1:05 PM Les <nagylzs@gmail.com> wrote:AFAIK PostgreSQL does not allow a row to occupy multiple blocks.Your plan is going to heavily involve out-of-band storage. Please read up on it here:
I'm aware of the TOAST, and how it works. I was referring to it ("I think that it should be as large as possible, without hitting the toast. ") I have designed a separate "block" table specifically to avoid storing binary data in the TOAST. So my plan is not going to involve out-of-band storage.
Just to make this very clear: a record in the block table would store a block, not the whole file. My question is to finding the optimal block size (without hitting the toast), and finding the optimal hash algorithm for block de-duplication.
Unless I totally misunderstood how the TOAST works. (?)
Laszlo
В списке pgsql-performance по дате отправления
