On Fri, Mar 18, 2022 at 1:35 AM Nathan Bossart wrote:
>
>
> I guess I think we should be slightly more ambitious. One idea could be to
> create a default_toast_compression_ratio GUC with a default of 0.95. This
> means that, by default, a compressed attribute must be 0.95x or less of the
> size
On Wed, Mar 23, 2022 at 9:58 AM Michael Paquier wrote:
>
> On Tue, Mar 22, 2022 at 02:42:53PM -0700, Nathan Bossart wrote:
> > On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
> >> Then, too, I'm not very confident about the usefulness of EXTENDED,
> >> EXTERNAL, and MAIN. I think
On Tue, Mar 22, 2022 at 02:42:53PM -0700, Nathan Bossart wrote:
> On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
>> Then, too, I'm not very confident about the usefulness of EXTENDED,
>> EXTERNAL, and MAIN. I think it's useful to be able to categorically
>> disable compression (as
On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
> We seem to have a shortage of "others" showing up with opinions on
> this topic, but I guess I'm not very confident about the general
> utility of such a setting. Just to be clear, I'm also not very
> confident about the usefulness of
On Thu, Mar 17, 2022 at 4:05 PM Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 01:04:17PM -0400, Robert Haas wrote:
> > Right, so perhaps the ultimate thing here would be a more fine-grained
> > knob than SET STORAGE EXTERNAL -- something that allows you to specify
> > that you want to compress
On Thu, Mar 17, 2022 at 01:04:17PM -0400, Robert Haas wrote:
> Right, so perhaps the ultimate thing here would be a more fine-grained
> knob than SET STORAGE EXTERNAL -- something that allows you to specify
> that you want to compress only when it really helps. While some people
> might find that
On Wed, Mar 16, 2022 at 2:36 PM Nathan Bossart wrote:
> Thinking further, is simply reducing the number of TOAST chunks the right
> thing to look at? If I want to add a TOAST attribute that requires 100,000
> chunks, and you told me that I could save 10% in the read path for an extra
> 250
On Wed, Mar 16, 2022 at 11:36:56AM -0700, Nathan Bossart wrote:
> Thinking further, is simply reducing the number of TOAST chunks the right
> thing to look at? If I want to add a TOAST attribute that requires 100,000
> chunks, and you told me that I could save 10% in the read path for an extra
>
On Wed, Mar 16, 2022 at 10:08:45AM -0400, Robert Haas wrote:
> I would like to take a slightly contrary position. I think that a
> system here that involves multiple knobs is going to be too
> complicated to be of any real-world use, because almost nobody will
> understand it or tune it properly
On Tue, Mar 15, 2022 at 5:48 PM Nathan Bossart wrote:
> I apologize for thinking out loud a bit here, but I hope this gives you
> some insight into my perspective on this. In general, I am skeptical that
> we can choose one threshold that will work for all PostgreSQL installations
> in the known
On Wed, Mar 16, 2022 at 01:03:38AM +0530, davinder singh wrote:
> Regarding the 2nd part of configuring the threshold, Based on our
> experiments, we have fixed it for the attributes with size > 2 * chunk_size.
> The default chunk_size is 2KB and the page size is 8KB. While toasting each
>
Thanks, Nathan, for the review comments. Please find the updated patch.
On Sun, Mar 13, 2022 at 3:43 AM Nathan Bossart
wrote:
> Do you think it is worth making this configurable? I don't think it is
> outside the realm of possibility for some users to care more about disk
> space than read
I think this is an interesting idea. My first thought is that it would be
nice if we didn't have to first compress the data to see whether we wanted
to store it compressed or not, but I don't think there is much we can do
about that. In any case, we aren't adding much work in the write path
On Thu, Mar 10, 2022 at 2:04 PM davinder singh
wrote:
>
> Thanks Dilip, I have fixed your comments, please find the updated patch.
>
Some more comments
+/*
+ * For those cases where storing compressed data is not optimal,
We will use
+ * this pointer copy for referring uncompressed
Thanks Dilip, I have fixed your comments, please find the updated patch.
On Tue, Mar 8, 2022 at 9:44 PM Dilip Kumar wrote:.
> +/* incompressible, ignore on subsequent compression passes. */
> +orig_attr->tai_colflags |= TOASTCOL_INCOMPRESSIBLE;
>
> Do we need to set
On Mon, Feb 28, 2022 at 3:22 PM davinder singh
wrote:
>
> Hi,
>
> For Toast storage [1] in PostgreSQL, first, the attribute value is compressed
> and then divided into chunks. The problem with storing compressed value is,
> if we
> are not saving enough space such that it reduces the #chunks
Hi,
For Toast storage [1] in PostgreSQL, first, the attribute value is
compressed
and then divided into chunks. The problem with storing compressed value is,
if we
are not saving enough space such that it reduces the #chunks then we end up
adding extra decompression cost on every read.
Based on
17 matches
Mail list logo
