Re: Efficient output for integer types

On Wed, Sep 18, 2019 at 05:42:01AM +0200, David Fetter wrote: > On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote: > > On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote: > > > On Sun, Sep 15, 2019 at 09:18:49AM +0200, David Fetter wrote: > > > > Folks, > > > > > > > > Please

Re: Creating partitions automatically at least on HASH?

Hello Fabien, Rafia, Thanks for starting this discussion. On Tue, Aug 27, 2019 at 5:36 PM Rafia Sabih wrote: > On Mon, 26 Aug 2019 at 19:46, Fabien COELHO wrote: >> > I happen to start a similar discussion [1] being unaware of this one >> > and there Ashutosh Sharma talked about interval partit

Re: Efficient output for integer types

On Wed, Sep 18, 2019 at 07:51:42AM +0200, David Fetter wrote: > On Wed, Sep 18, 2019 at 05:42:01AM +0200, David Fetter wrote: > > On Tue, Sep 17, 2019 at 09:01:57AM +0200, David Fetter wrote: > > > On Tue, Sep 17, 2019 at 08:55:05AM +0200, David Fetter wrote: > > > > On Sun, Sep 15, 2019 at 09:18:4

Re: pgbench - allow to create partitioned tables

Hi Fabien, On Wed, Sep 18, 2019 at 3:49 AM Fabien COELHO wrote: > Attached v9: Thanks. This seems to work well. Couple of nitpicks on parameter error messages. +fprintf(stderr, "invalid partition type, expecting \"range\" or \"hash\"," How about "partitioning method" inst

Proposal: Add more compile-time asserts to expose inconsistencies.

Dear Hackers, I have identified some OSS code where more compile-time asserts could be added. Mostly these are asserting that arrays have the necessary length to accommodate the enums that are used to index into them. In general the code is already commented with warnings such as: * "If you ad

Re: logical decoding : exceeded maxAllocatedDescs for .spill files

On Tue, 17 Sep 2019 at 21:19, Andres Freund wrote: > On 2019-09-14 14:34:21 -0400, Tom Lane wrote: > > Amit Khandekar writes: > > > Yeah, something like the attached patch. I think this tracking of > > > offsets would have been cleaner if we add in-built support in VFD. But > > > yeah, for bank b

Don't codegen deform code for virtual tuples in expr eval for scan fetch

Hello Hackers, This is to address a TODO I found in the JIT expression evaluation code (opcode = EEOP_INNER_FETCHSOME/EEOP_OUTER_FETCHSOME/EEOP_SCAN_FETCHSOME): * TODO: skip nvalid check if slot is fixed and known to * be a virtual slot. Not only should we skip the nvalid check if the tuple is v

<    1   2