Re: [HACKERS] CLUSTER command progress monitor

Hi Sawada-san, Thanks for taking your time. I'll be more careful. Regards, Tatsuro Yamada On 2017/09/04 11:51, Masahiko Sawada wrote: On Mon, Sep 4, 2017 at 11:37 AM, Tatsuro Yamada wrote: Hi Sawada-san, Thomas, Thanks for sharing the reggression.diff. I

Re: [HACKERS] Parallel worker error

On Wed, Aug 30, 2017 at 8:49 PM, Robert Haas wrote: > > > But since that's an established design fl^H^Hprinciple, maybe that > means we should go with the approach of teaching SerializeGUCState() > to ignore role altogether and instead have ParallelWorkerMain call >

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Thu, Aug 31, 2017 at 11:27 PM, Robert Haas wrote: I have repeated one of the tests after fixing the problems pointed by you but this time results are not that impressive. Seems like below check was the problem in the previous patch if (tbm->nentries >

Re: [HACKERS] pg_basebackup throttling doesn't throttle as promised

On Sat, Sep 2, 2017 at 6:42 AM, Jeff Janes wrote: > I'm attaching a patch for each option. Each one independently solves the > problem. But I think we should do both. There is no point in issuing > unnecessary kill system calls, and there may also be more spurious

Re: [HACKERS] dropping partitioned tables without CASCADE

Hi Ashutosh, On 2017/09/04 13:51, Ashutosh Bapat wrote: > Hi, > Thomas's application to track patches told me that this patch needs > rebase. It also required some changes to the code. Here's the updated > version. I have squashed those two patches together. Thanks for the rebased patch. Would

Re: [HACKERS] asynchronous execution

At Thu, 31 Aug 2017 21:52:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170831.215236.135328985.horiguchi.kyot...@lab.ntt.co.jp> > At Thu, 03 Aug 2017 09:30:57 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI >

Re: [HACKERS] dropping partitioned tables without CASCADE

Hi, Thomas's application to track patches told me that this patch needs rebase. It also required some changes to the code. Here's the updated version. I have squashed those two patches together. On Tue, Mar 14, 2017 at 6:35 PM, Ashutosh Bapat wrote: > Added this

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Sat, Sep 2, 2017 at 3:00 AM, Bossart, Nathan wrote: > Don't we have a similar problem with makeVacuumRelation() and list_make1()? Yeah, indeed. I forgot about this portion. > I went ahead and moved the RangeVar, VacuumRelation, and List into local > variables for now,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/04 12:38, Etsuro Fujita wrote: > On 2017/09/02 4:10, Ashutosh Bapat wrote: >> This rebase mainly changes patch 0001, which translates partition >> hierarchy into inheritance hierarchy creating AppendRelInfos and >> RelOptInfos for partitioned partitions. Because of that, it's not >>

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

On Mon, Sep 4, 2017 at 7:20 AM, Tom Lane wrote: > I wrote: > On further consideration, I think the control logic I added in > exec_simple_query() is a shade bogus. I set it up to only force > an implicit transaction block when there are at least two statements > remaining to

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/09/02 4:10, Ashutosh Bapat wrote: This rebase mainly changes patch 0001, which translates partition hierarchy into inheritance hierarchy creating AppendRelInfos and RelOptInfos for partitioned partitions. Because of that, it's not necessary to record the partitioned partitions in a

Re: [HACKERS] CLUSTER command progress monitor

On Mon, Sep 4, 2017 at 11:37 AM, Tatsuro Yamada wrote: > Hi Sawada-san, Thomas, > > Thanks for sharing the reggression.diff. > I realized Thomas's comment is right. > > Attached patch is fixed version. > Could you try it? > Yeah, in my environment the regression

Re: [HACKERS] Secondary index access optimizations

On 2017/09/02 12:44, Thomas Munro wrote: > On Wed, Aug 16, 2017 at 9:23 PM, Konstantin Knizhnik > wrote: >> postgres=# explain select * from bt where k between 1 and 2 and v = 100; >> QUERY PLAN >>

Re: [HACKERS] CLUSTER command progress monitor

Hi Sawada-san, Thomas, Thanks for sharing the reggression.diff. I realized Thomas's comment is right. Attached patch is fixed version. Could you try it? Regards, Tatsuro Yamada NTT Open Source Software Center On 2017/09/01 17:59, Masahiko Sawada wrote: On Fri, Sep 1, 2017 at 3:38 PM,

Re: [HACKERS] Fix warnings and typo in dshash

On Sun, Sep 3, 2017 at 2:56 PM, Thomas Munro wrote: > On Sun, Sep 3, 2017 at 6:57 PM, Amit Kapila wrote: >> I am seeing below warnings (on Win7) in dshash.c >> >> 1> dshash.c >> 1>src/backend/lib/dshash.c(318): warning C4334: '<<' : result

Re: [HACKERS] UPDATE of partition key

On Sun, Sep 3, 2017 at 5:10 PM, Amit Khandekar wrote: > On 31 August 2017 at 14:15, Amit Khandekar wrote: >> Thanks Dilip. I am working on rebasing the patch. Particularly, the >> partition walker in my patch depended on the fact that all the

Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization

On Fri, Sep 1, 2017 at 11:29 PM, Fabien COELHO wrote: > >>> I'm wondering whether this truncation should be yet another available >>> command? Hmmm... maybe not. >> >> >> Currently TRUNCATE pgbench_accounts command is executed within a >> transaction started immediately

Re: [HACKERS] INSERT .. ON CONFLICT DO SELECT [FOR ..]

On Tue, Aug 15, 2017 at 12:17 AM, Marko Tiikkaja wrote: > On Tue, Aug 15, 2017 at 7:43 AM, Peter Geoghegan wrote: >> >> On Mon, Aug 14, 2017 at 6:23 PM, Marko Tiikkaja wrote: >> > Attached is a patch for $SUBJECT. It might still be a bit rough around

Re: [HACKERS] path toward faster partition pruning

Thanks for the comments. On 2017/09/02 2:52, Robert Haas wrote: > On Thu, Aug 31, 2017 at 2:02 AM, Amit Langote > wrote: >> Attached is now also the set of patches that implement the actual >> partition-pruning logic, viz. the last 3 patches (0004, 0005, and 0006)

Re: [HACKERS] expanding inheritance in partition bound order

Hi Amit, On 2017/09/03 16:07, Amit Khandekar wrote: > On 31 August 2017 at 13:06, Amit Langote > wrote: >>> Mind you, that idea has some problems anyway in the face of default >>> partitions, null partitions, and list partitions which accept >>> non-contiguous

Re: odd behavior/possible bug (Was: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug)

On 09/03/2017 03:34 PM, Tom Lane wrote: > Joe Conway writes: >> Notice that tsr is not empty at all on the first loop, but on the second >> loop it is empty every second time the trigger fires. > > I think the issue is that now() isn't changing within the transaction, > so

Re: odd behavior/possible bug (Was: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug)

Joe Conway writes: > Notice that tsr is not empty at all on the first loop, but on the second > loop it is empty every second time the trigger fires. I think the issue is that now() isn't changing within the transaction, so when you construct "tstzrange(lower(OLD.tr), now(),

odd behavior/possible bug (Was: Re: [HACKERS] PG10 partitioning - odd behavior/possible bug)

On 09/03/2017 02:28 PM, Joe Conway wrote: > I was playing around with partitioning and found an oddity that is best > described with the following reasonably minimal test case: > Notice that in the first loop iteration tsr is calculated from OLD.tr > correctly. But in the second loop iteration

Re: [HACKERS] [bug fix] Savepoint-related statements terminates connection

I wrote: > ... PFA a patch > that invents a notion of an "implicit" transaction block. On further consideration, I think the control logic I added in exec_simple_query() is a shade bogus. I set it up to only force an implicit transaction block when there are at least two statements remaining to

[HACKERS] PG10 partitioning - odd behavior/possible bug

I was playing around with partitioning and found an oddity that is best described with the following reasonably minimal test case: 8<- CREATE TABLE timetravel ( id int8, f1 text not null, tr tstzrange not null default tstzrange(now(), 'infinity', '[]') ) PARTITION BY RANGE

Re: [HACKERS] adding the commit to a patch's thread

> On 03 Sep 2017, at 21:12, Magnus Hagander wrote: > > On Sun, Sep 3, 2017 at 8:55 PM, Daniel Gustafsson > wrote: > > That leaves us back at parsing/scraping -committers and adding the mailthread. > For this CF I can add the

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 02 Sep 2017, at 02:21, Thomas Munro wrote: > > On Fri, Jun 23, 2017 at 1:48 AM, Daniel Gustafsson wrote: >> Good point. I’ve attached a new version which issues a NOTICE on truncation >> and also addresses all other comments so far in this

Re: [HACKERS] [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?

From: Henry M > This may be interesting... they implement cypher (unfortunately they had to fork in order to have cypher be a first class query language with SQL). > > https://github.com/bitnine-oss/agensgraph I'm sorry for my very late reply. Thanks for the information. AgensGraph is certainly

Re: [HACKERS] Function to move the position of a replication slot

On Sun, Sep 3, 2017 at 12:20 AM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 11:30 PM, Peter Eisentraut > wrote: > > On 8/31/17 08:19, Magnus Hagander wrote: > >> Rebased. Now named pg_advance_replication_slot. ERROR on logical slots. >

Re: [HACKERS] adding the commit to a patch's thread

On Sun, Sep 3, 2017 at 8:55 PM, Daniel Gustafsson wrote: > > On 03 Sep 2017, at 19:33, Magnus Hagander wrote: > > > > On Sun, Sep 3, 2017 at 12:00 AM, Daniel Gustafsson > wrote: > > > On 01 Sep 2017, at 15:40,

Re: [HACKERS] adding the commit to a patch's thread

> On 03 Sep 2017, at 19:33, Magnus Hagander wrote: > > On Sun, Sep 3, 2017 at 12:00 AM, Daniel Gustafsson > wrote: > > On 01 Sep 2017, at 15:40, Robert Haas > > wrote: > > > >

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

Nikolay Shaplov wrote: > В письме от 25 июня 2017 21:05:49 пользователь Nikolay Shaplov написал: > > I've just made sure that patch is still applyable to the current master. > > And I am still waiting for reviews :-) I see that this patch adds a few tests for reloptions, for instance in bloom.

Re: [HACKERS] JIT & function naming

On 2017-09-03 10:11:37 -0400, Tom Lane wrote: > Andres Freund writes: > > Currently there's essentially a per EState counter and the generated > > functions get named deform$n and evalexpr$n. That allows for profiling > > of a single query, because different compiled

Re: [HACKERS] adding the commit to a patch's thread

On Sun, Sep 3, 2017 at 12:00 AM, Daniel Gustafsson wrote: > > On 01 Sep 2017, at 15:40, Robert Haas wrote: > > > > On Fri, Sep 1, 2017 at 4:26 AM, Alvaro Herrera > wrote: > >> Erik Rijkers wrote: > >>> Would it be possible to

Re: [HACKERS] Fix warnings and typo in dshash

Thomas Munro writes: > Aside from these 3 warnings, it looks like the other 17 are all > "warning C4005: 'HAVE_LONG_LONG_INT_64': macro redefinition". Oh, I think that one might be my fault. I tweaked pg_config.h.win32 in 9d6b160d7 to use "#define

Re: [HACKERS] Fix warnings and typo in dshash

Amit Kapila writes: > I am seeing below warnings (on Win7) in dshash.c > 1> dshash.c > 1>src/backend/lib/dshash.c(318): warning C4334: '<<' : result of > 32-bit shift implicitly converted to 64 bits (was 64-bit shift > intended?) > 1>src/backend/lib/dshash.c(679):

Re: [HACKERS] JIT & function naming

Andres Freund writes: > Currently there's essentially a per EState counter and the generated > functions get named deform$n and evalexpr$n. That allows for profiling > of a single query, because different compiled expressions are > disambiguated. It even allows to run the same

Re: [HACKERS] Adding support for Default partition in partitioning

On Sat, Sep 2, 2017 at 7:03 AM, Robert Haas wrote: > On Fri, Sep 1, 2017 at 3:19 PM, Robert Haas wrote: > > On Thu, Aug 31, 2017 at 8:53 AM, Jeevan Ladhe > > wrote: > >> 0001: > >> This patch refactors

Re: [HACKERS] UPDATE of partition key

On 31 August 2017 at 14:15, Amit Khandekar wrote: > Thanks Dilip. I am working on rebasing the patch. Particularly, the > partition walker in my patch depended on the fact that all the tables > get opened (and then closed) while creating the tuple routing info. > But in

Re: [HACKERS] Fix warnings and typo in dshash

On Sun, Sep 3, 2017 at 6:57 PM, Amit Kapila wrote: > I am seeing below warnings (on Win7) in dshash.c > > 1> dshash.c > 1>src/backend/lib/dshash.c(318): warning C4334: '<<' : result of > 32-bit shift implicitly converted to 64 bits (was 64-bit shift > intended?) >

Re: [HACKERS] expanding inheritance in partition bound order

On 31 August 2017 at 13:06, Amit Langote wrote: >> Mind you, that idea has some problems anyway in the face of default >> partitions, null partitions, and list partitions which accept >> non-contiguous values (e.g. one partition for 1, 3, 5; another for 2, >> 4, 6).

Re: [HACKERS] JIT & function naming

On 09/03/2017 02:59 AM, Andres Freund wrote: Hi, On 2017-08-31 23:41:31 -0700, Andres Freund wrote: I previously had an early prototype of JITing [1] expression evaluation and tuple deforming. I've since then worked a lot on this. Here's an initial, not really pretty but functional,

[HACKERS] Fix warnings and typo in dshash

I am seeing below warnings (on Win7) in dshash.c 1> dshash.c 1>src/backend/lib/dshash.c(318): warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) 1>src/backend/lib/dshash.c(679): warning C4334: '<<' : result of 32-bit shift implicitly