On Thu, Nov 14, 2019 at 6:30 PM Tomas Vondra
wrote:
> On Thu, Nov 14, 2019 at 03:27:42PM +0530, Rushabh Lathia wrote:
> >Today I noticed strange behaviour, consider the following test:
> >
> >postgres@126111=#create table foo ( a text );
> >CREATE TABLE
> >postgres@126111=#insert into foo values
On Thu, Nov 14, 2019 at 03:27:42PM +0530, Rushabh Lathia wrote:
Today I noticed strange behaviour, consider the following test:
postgres@126111=#create table foo ( a text );
CREATE TABLE
postgres@126111=#insert into foo values ( repeat('PostgreSQL is the
world''s best database and leading by an
Today I noticed strange behaviour, consider the following test:
postgres@126111=#create table foo ( a text );
CREATE TABLE
postgres@126111=#insert into foo values ( repeat('PostgreSQL is the
world''s best database and leading by an Open Source Community.', 8000));
INSERT 0 1
postgres@126111=#sele
Tomas Vondra writes:
> On Tue, Oct 01, 2019 at 10:10:37AM -0400, Tom Lane wrote:
>> Maybe it accidentally seems to work on little-endian, thanks to the
>> different definitions of varlena headers?
> Maybe. Let's see if just using VARSIZE_ANY does the trick. If not, I'll
> investigate further.
FW
On Tue, Oct 01, 2019 at 10:10:37AM -0400, Tom Lane wrote:
Tomas Vondra writes:
Hmmm, this seems to trigger a failure on thorntail, which is a sparc64
machine (and it seems to pass on all x86 machines, so far).
gharial's not happy either, and I bet if you wait a bit longer you'll
see the same
Tomas Vondra writes:
> Hmmm, this seems to trigger a failure on thorntail, which is a sparc64
> machine (and it seems to pass on all x86 machines, so far).
gharial's not happy either, and I bet if you wait a bit longer you'll
see the same on other big-endian machines.
> I wonder if that's wrong,
On Tue, Oct 01, 2019 at 02:34:20PM +0200, Tomas Vondra wrote:
On Tue, Oct 01, 2019 at 12:08:05PM +0200, Tomas Vondra wrote:
On Tue, Oct 01, 2019 at 11:20:39AM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 22:29, Tomas Vondra
написал(а):
On Mon, Sep 30, 2019 at 09:20:22PM +0500, Andrey
On Tue, Oct 01, 2019 at 12:08:05PM +0200, Tomas Vondra wrote:
On Tue, Oct 01, 2019 at 11:20:39AM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 22:29, Tomas Vondra
написал(а):
On Mon, Sep 30, 2019 at 09:20:22PM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 20:56, Tomas Vondra
на
On Tue, Oct 01, 2019 at 11:20:39AM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 22:29, Tomas Vondra
написал(а):
On Mon, Sep 30, 2019 at 09:20:22PM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 20:56, Tomas Vondra
написал(а):
I mean this:
/*
* Use int64 to prevent overflow
> 30 сент. 2019 г., в 22:29, Tomas Vondra
> написал(а):
>
> On Mon, Sep 30, 2019 at 09:20:22PM +0500, Andrey Borodin wrote:
>>
>>
>>> 30 сент. 2019 г., в 20:56, Tomas Vondra
>>> написал(а):
>>>
>>> I mean this:
>>>
>>> /*
>>> * Use int64 to prevent overflow during calculation.
>>>
On Mon, Sep 30, 2019 at 09:20:22PM +0500, Andrey Borodin wrote:
30 сент. 2019 г., в 20:56, Tomas Vondra
написал(а):
I mean this:
/*
* Use int64 to prevent overflow during calculation.
*/
compressed_size = (int32) ((int64) rawsize * 9 + 8) / 8;
I'm not very familiar with pglz int
> 30 сент. 2019 г., в 20:56, Tomas Vondra
> написал(а):
>
> I mean this:
>
> /*
>* Use int64 to prevent overflow during calculation.
>*/
> compressed_size = (int32) ((int64) rawsize * 9 + 8) / 8;
>
> I'm not very familiar with pglz internals, but I'm a bit puzzled by
> this. My
On Fri, Sep 27, 2019 at 01:00:36AM +0200, Tomas Vondra wrote:
On Wed, Sep 25, 2019 at 05:38:34PM -0300, Alvaro Herrera wrote:
Hello, can you please update this patch?
I'm not the patch author, but I've been looking at the patch recently
and I have a rebased version at hand - so attached.
FWI
drant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 7167c0e5f78d74a0c02a76748e7b8caaabe65ccd Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Fri, 27 Sep 2019 00:51:52 +0200
Subject: [PATCH] Optimize partial TOAST decompression
---
src/backend/ac
Hello, can you please update this patch?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Jul 10, 2019 at 01:35:25PM +0800, Binguo Bao wrote:
Tomas Vondra 于2019年7月10日周三 上午5:12写道：
On Sat, Jul 06, 2019 at 05:23:37PM +0200, Tomas Vondra wrote:
>On Sat, Jul 06, 2019 at 02:27:56AM +0800, Binguo Bao wrote:
>>Hi, Tomas!
>>Thanks for your testing and the suggestion.
>>
>>That's qui
op in almost all
cases.
Besides, If a value is composed of random characters,
it will be hard to be compressed, because pglz requires a 25% compression
ratio by default or not worth it.
This means that querying the value will not trigger the patch. But the
first test results show that the patch
is slo
On Sat, Jul 06, 2019 at 05:23:37PM +0200, Tomas Vondra wrote:
On Sat, Jul 06, 2019 at 02:27:56AM +0800, Binguo Bao wrote:
Hi, Tomas!
Thanks for your testing and the suggestion.
That's quite bizarre behavior - it does work with a prefix, but not with
suffix. And the exact ERROR changes after th
rt, Remote DBA, Training & Services
>From d50ae41bf1d1c4e2786a55a610300606c1ec43a5 Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Sat, 6 Jul 2019 15:41:37 +0200
Subject: [PATCH 1/2] Optimize partial TOAST decompression
---
src/backend/access/heap/tuptoaster.c | 57 ++--
the macro "TOAST_COMPRESS_RAWDATA" to
"TOAST_COMPRESS_DATA" since
it is used to get toast compressed data rather than raw data.
Best Regards, Binguo Bao.
From bcf04278b4d5956cd5f5fdab0d954b36adfd0022 Mon Sep 17 00:00:00 2001
From: BBG
Date: Sun, 2 Jun 2019 19:18:46 +0800
Subje
Of course, I forgot to attach the files, so here they are.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t.data.gz
Description: application/gzip
(gdb) bt
#0 toast_decompress_datum (attr=0x12572e0) at
On Thu, Jul 04, 2019 at 11:10:24AM +0200, Andrey Borodin wrote:
3 июля 2019 г., в 18:06, Binguo Bao написал(а):
Paul Ramsey 于2019年7月2日周二 下午10:46写道：
This looks good to me. A little commentary around why
pglz_maximum_compressed_size() returns a universally correct answer
(there's no way the co
> 3 июля 2019 г., в 18:06, Binguo Bao написал(а):
>
> Paul Ramsey 于2019年7月2日周二 下午10:46写道：
> This looks good to me. A little commentary around why
> pglz_maximum_compressed_size() returns a universally correct answer
> (there's no way the compressed size can ever be larger than this
> because..
it.
Any comments would be much appreciated.
Best Regards, Binguo Bao.
[0]
https://www.postgresql.org/message-id/flat/cal-ogks_onzpc9m9bxpcztmofwulcfkyecekiagxzwrl8kx...@mail.gmail.com
From 2e4e2838937ec6fa1404fe529e7ed303e391d1b2 Mon Sep 17 00:00:00 2001
From: BBG
Date: Sun, 2 Jun 2019 19:18:46 +08
On Mon, Jul 1, 2019 at 6:46 AM Binguo Bao wrote:
> > Andrey Borodin 于2019年6月29日周六 下午9:48写道：
>> I've took a look into the code.
>> I think we should extract function for computation of max_compressed_size
>> and put it somewhere along with pglz code. Just in case something will
>> change somethi
;ve corrected the related code in the patch.
> > ...
> > <0001-Optimize-partial-TOAST-decompression-2.patch>
>
> I've took a look into the code.
> I think we should extract function for computation of max_compressed_size
> and put it somewhere along with pglz co
t; into at least L bytes of data. At worst we have one control byte per 8 bytes
>> of literal bytes. This means at most we need (L*9 + 8) / 8 bytes with
>> current pglz format.
>
> Good catch! I've corrected the related code in the patch.
> ...
> <0001-Optimize-part
(L*9 + 8) / 8
> bytes with current pglz format.
>
> Also, I'm not sure you use SET_VARSIZE_COMPRESSED correctly...
>
> Best regards, Andrey Borodin.
From 505dcc4fdef18710c98718685180190056b4d9ed Mon Sep 17 00:00:00 2001
From: BBG
Date: Sun, 2 Jun 2019 19:18:46 +0800
Subject: [PAT
Hi, Binguo!
> 2 июня 2019 г., в 19:48, Binguo Bao написал(а):
>
> Hi, hackers!
> This seems to have a 10x improvement. If the number of toast data chunks is
> more, I believe that patch can play a greater role, there are about 200
> related TOAST data chunks for each entry in the case.
T
ab367e4b7bf62f39 Mon Sep 17 00:00:00 2001
From: BBG
Date: Sun, 2 Jun 2019 19:18:46 +0800
Subject: [PATCH] Optimize partial TOAST decompression
---
src/backend/access/heap/tuptoaster.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/backend/access/hea
30 matches
Mail list logo
