On Tue, Feb 19, 2019 at 05:09:33PM +0900, Masahiko Sawada wrote:
> On Tue, Feb 19, 2019 at 1:28 AM Andres Freund wrote:
>> Well, I'd not thought we'd do it without acquiring the other slot. But
>> that still seems to be easy enough to address, we just need to recheck
>> whether the slot still exis
Some time ago I posted PoC patch with alternative TOAST compression scheme:
instead of "compress-then-chunk" I suggested "chunk-then-compress". It
decrease compression level, but allows efficient arbitrary slicing.
ср, 20 февр. 2019 г., 2:09 Paul Ramsey pram...@cleverelephant.ca:
> On Sat, Feb 16
On Mon, Feb 18, 2019 at 10:45:38AM -0300, Alvaro Herrera wrote:
> None here.
Thanks. And committed.
--
Michael
signature.asc
Description: PGP signature
On Mon, Feb 4, 2019 at 2:31 PM Haribabu Kommi
wrote:
>
> On Tue, Jan 22, 2019 at 1:43 PM Haribabu Kommi
> wrote:
>
>>
>>
>> OK. I will work on the doc changes.
>>
>
> Sorry for the delay.
>
> Attached a draft patch of doc and comments changes that I worked upon.
> Currently I added comments to t
On Tue, Nov 27, 2018 at 4:59 PM Amit Langote
wrote:
> Hi,
>
> On 2018/11/02 9:17, Haribabu Kommi wrote:
> > Here I attached the cumulative fixes of the patches, new API additions
> for
> > zheap and
> > basic outline of the documentation.
>
> I've read the documentation patch while also looking a
On Mon, Feb 18, 2019 at 10:06 PM Jamison, Kirk wrote:
> It sounds more logical to me if there is a parameter that switches on/off the
> logging
> similar to other postgres logs. I suggest trace_log as the parameter name.
I'm not really sure that I like the design of this patch in any way.
But le
On Wed, Feb 20, 2019 at 12:26 PM Michael Paquier wrote:
>
> On Tue, Feb 19, 2019 at 05:09:33PM +0900, Masahiko Sawada wrote:
> > On Tue, Feb 19, 2019 at 1:28 AM Andres Freund wrote:
> >> Well, I'd not thought we'd do it without acquiring the other slot. But
> >> that still seems to be easy enough
At Thu, 14 Feb 2019 00:40:10 -0800, Andres Freund wrote in
<20190214084010.bdn6tmba2j7sz...@alap3.anarazel.de>
> Hi,
>
> On 2019-02-13 15:31:14 +0900, Kyotaro HORIGUCHI wrote:
> > Instead, I added an accounting(?) interface function.
> >
> > | MemoryContextGettConsumption(MemoryContext cxt);
>
On Fri, Feb 15, 2019 at 10:15 AM Michael Paquier
wrote:
> On Thu, Feb 14, 2019 at 11:21:19PM +1100, Haribabu Kommi wrote:
> > On Thu, Feb 14, 2019 at 8:57 PM Magnus Hagander
> wrote:
> >> I think it could be argued that neither initdb *or* pg_basebackup should
> >> change the permissions on an e
On Wed, Feb 20, 2019 at 2:18 PM Nikita Glukhov wrote:
> On 04.02.2019 8:35, Michael Paquier wrote:
> This patch set needs a rebase because of conflicts caused by the
> recent patches for pluggable storage.
Hi Nikita,
>From the department of trivialities: according to cfbot the
documentation doesn
On Wed, Feb 20, 2019 at 03:16:48PM +1100, Haribabu Kommi wrote:
> Lack of complaints from the users, how about making this change in the HEAD?
Fine by me. I would tend to patch pg_basebackup so as the target
folder gets the correct umask instead of nuking the chmod call in
initdb so I think that
Amit Langote writes:
> On 2019/02/20 6:48, Tom Lane wrote:
>> What if we dropped that idea, and instead defined the plan tree as
>> returning only the columns that are updated by SET, plus the row
>> identity? It would then be the ModifyTable node's job to fetch the
>> original tuple using the ro
On Wed, Feb 20, 2019 at 4:23 AM David Rowley
wrote:
> On Wed, 20 Feb 2019 at 10:49, Tom Lane wrote:
> > What if we dropped that idea, and instead defined the plan tree as
> > returning only the columns that are updated by SET, plus the row
> > identity? It would then be the ModifyTable node's j
Pavan Deolasee writes:
> We will need to consider how this affects EvalPlanQual which currently
> doesn't have to do anything special for partitioned tables. I solved that
> via tracking the expanded-at-the-bottom child in a separate
> mergeTargetRelation, but that approach has been criticised. Ma
From: Tomas Vondra [mailto:tomas.von...@2ndquadrant.com]
> On 2/12/19 7:33 AM, Tsunakawa, Takayuki wrote:
> > Imai-san confirmed performance improvement with this patch:
> >
> > https://commitfest.postgresql.org/22/1993/
> >
>
> Can you quantify the effects? That is, how much slower/faster does it
On 2019/02/20 5:57, Tom Lane wrote:
> I wrote:
>> OK, I'll make another pass over 0001 today.
>
> So I started the day with high hopes for this, but the more I looked at
> it the less happy I got, and finally I ran into something that looks to
> be a complete show-stopper. Namely, that the patch
Hi,
I tried to re-read the whole thread.
Based from what I read, there are two proposed timeout parameters,
which I think can be discussed and commited separately:
(1) tcp_user_timeout
(2) tcp_socket_timeout (or suggested client_statement_timeout,
send_timeout/recv_timeout
On Sun, Jan 06, 2019 at 06:28:11PM +0300, Nikolay Shaplov wrote:
> Actually I am not satisfied with it too... That is why I started that bigger
> reloptions refactoring work. So for now I would offer to keep initialization
> as it was for other types: in initialize_reloptions using [type]RelOpts
Before addressing to speeding up creating generic plan of UPDATE/DELETE, I will
begin with the speed up creating SELECT plan.
I will explain the background as time has passed.
Since generic plan creates plans of all partitions and is cached, we can skip
planning and expect performance improvemen
On Tue, Feb 19, 2019 at 12:27 PM Michael Paquier wrote:
>
> On Mon, Feb 18, 2019 at 05:05:13PM +0100, Oleksii Kliukin wrote:
> > That looks like a race condition to me. What happens is that another
> > transaction with the name identical to the running one can start and proceed
> > to the prepare
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> Hm. Putting a list header for a purely-local data structure into shared
> memory seems quite ugly. Isn't there a better place to keep that?
Agreed. I put it in the global variable.
> Do we really want a dlist here at all? I'm concerned that bloati
В письме от среда, 20 февраля 2019 г. 15:08:32 MSK пользователь Michael
Paquier написал:
> On Sun, Jan 06, 2019 at 06:28:11PM +0300, Nikolay Shaplov wrote:
> > Actually I am not satisfied with it too... That is why I started that
> > bigger reloptions refactoring work. So for now I would offer to
At Fri, 15 Feb 2019 15:53:28 -0300, Alvaro Herrera
wrote in <20190215185328.GA29663@alvherre.pgsql>
> On 2019-Feb-15, Andres Freund wrote:
>
> > It's fine to do such renames, just do them as separate patches. It's
> > hard enough to review changes this big...
>
> Talk about moving the whole fil
On Wednesday, February 20, 2019 12:43:50 AM CET Laurenz Albe wrote:
> Pierre Ducroquet wrote:
> > In order to increase our security, we have started deploying row-level
> > security in order to add another safety net if any issue was to happen in
> > our applications.
> > After a careful monitoring
On 2019/02/20 13:54, Tom Lane wrote:
> Amit Langote writes:
>> On 2019/02/20 6:48, Tom Lane wrote:
>>> What if we dropped that idea, and instead defined the plan tree as
>>> returning only the columns that are updated by SET, plus the row
>>> identity? It would then be the ModifyTable node's job
101 - 125 of 125 matches
Mail list logo
