Re: How to store "blobs" efficiently for small and large sizes, with random access
| От | Alvaro Herrera | 
|---|---|
| Тема | Re: How to store "blobs" efficiently for small and large sizes, with random access | 
| Дата | |
| Msg-id | 20221019153006.zmzz4hljtkbo456c@alvherre.pgsql обсуждение исходный текст  | 
		
| Ответ на | Re: How to store "blobs" efficiently for small and large sizes, with random access (Dominique Devienne <ddevienne@gmail.com>) | 
| Ответы | 
                	
            		Re: How to store "blobs" efficiently for small and large sizes, with random access
            		
            		 | 
		
| Список | pgsql-general | 
On 2022-Oct-19, Dominique Devienne wrote: > Anybody has an answer to my question regarding how substr() works on > bytea values? I.e. is it "pushed down" / optimized enough that it > avoids reading the whole N-byte value, to then pass it to substr(), > which then returns an M-byte value (where M < N)? > > If TOAST stores 2,000 chunks, and those chunks' PKs are numbers, > simple arithmetic should be able to select only the chunks of > interest, those incurring only the necessary IO for the selected > range, no? That's exactly what I was trying to say. If there's no compression, we don't read prior chunks. (This is valid for bytea, at least; for textual types we have to worry about multibyte characters, which are again a potential source of confusion regarding the exact location you want to seek.) This can be seen in detoast_attr_slice() in src/backend/access/common/detoast.c, though there are way too many^W^W^W multiple layers of indirection if you start from bytea_substr() in varlena.c. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
В списке pgsql-general по дате отправления: