Nikita Malakhov <hukutoc@gmail.com> writes:
Hello Nikita,
>
> For EXPANDED attributes va_rawsize is the size of the compressed attribute, not original size.
> You can check toast_save_datum for that.
Here is some quota from toast_save_datum, which is different from what
you are saying here.
* Get the data pointer and length, and compute va_rawsize and va_extinfo.
*
* va_rawsize is the size of the equivalent fully uncompressed datum, so
* we have to adjust for short headers.
*
* va_extinfo stored the actual size of the data payload in the toast
* records and the compression method in first 2 bits if data is
* compressed.
I might be wrong anyway, but if you want to feedback on the va_rawsize,
could you quota the part I said for that? otherwise I am feeling all of
my effort is ignored, and I'm not sure if you really read my post
carefully. I think this would cause some inefficient communication.
"""
I thought 'toast_raw_datum_size' is the existing function to get the
"detoasted length" for the caller of detoast_attr_buffer, so it looks
reasonable for me to assume the caller knows how to get the detoast
length.
What really confused me suddenly is it is really correct to use
"toast_raw_datum_size". In "toast_raw_datum_size":
if (VARATT_IS_EXTERNAL_ONDISK(attr))
{
/* va_rawsize is the size of the original datum -- including header */
struct varatt_external toast_pointer;
VARATT_EXTERNAL_GET_POINTER(toast_pointer, attr);
result = toast_pointer.va_rawsize;
}
We just return the va_rawsize directly. Does it work for a datum which
is compressed first and then stored on external ondisk? After some
more research, it is correct since the rawsize is the size of
uncompressed data. and we also use the fact in
1b393f4e5db4fd6bbc86a4e88785b6945a1541d0. This is why I said...
"""
> This thread looks like the second take of the shared detoast datum
> patch. Have you checked my proposals in that thread?
At the start of this thread, I wrote the user case as below:
Qutoa here again:
"""
There are 2 user cases at least:
1. The shared detoast datum patch at [1], where I want to avoid the
duplicated detoast effort for the same datum.
2.make printtup function a bit faster [2].
"""
If you check it carefully, you would find they have different needs
and detoast_attr_buffer can meets the two needs at the same time.
As to your prososal, I remember you want to redesign the storage for
detoast, but then there is no detailed design or code later, which makes
me confused about the state of this direction. But if you want to talk
about this, could we discuss on its own thread?
Thanks
--
Best Regards
Andy Fan
