Re: [HACKERS] Proposal: Local indexes for partitioned table

On 13 November 2017 at 12:55, Alvaro Herrera wrote: > Somehow I managed to include an unrelated patch as attachment. Here's > another attempt (on which I also lightly touched ddl.sgml with relevant > changes). Looks good. Some minor comments below. 0001- Simplify Seems

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

On Mon, Oct 30, 2017 at 9:49 AM, Nikolay Shaplov wrote: > В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал: > > Yet another git rebase. This patch can be applied to master branch again. > > For this patch no review needed now, as I will offer part of it

Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

Thank you for pointing out and comments. On Fri, Nov 10, 2017 at 12:38 AM, Tom Lane wrote: > Robert Haas writes: >> No, that's not right. Now that you mention it, I realize that tuple >> locks can definitely cause deadlocks. Example: > > Yeah.

Re: [HACKERS] Runtime Partition Pruning

PFA the updated patches. On Tue, Nov 14, 2017 at 11:45 AM, Beena Emerson wrote: > Hello Amul, > > Thank you for reviewing. > > On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote: >> On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson

Re: [HACKERS] Runtime Partition Pruning

Hello Amul, Thank you for reviewing. On Fri, Nov 10, 2017 at 4:33 PM, amul sul wrote: > On Thu, Nov 9, 2017 at 4:48 PM, Beena Emerson wrote: >> Hello all, >> >> Here is the updated patch which is rebased over v10 of Amit Langote's >> path towards

Re: FP16 Support?

On Tue, Nov 14, 2017 at 6:49 PM, Kohei KaiGai wrote: > 2017-11-14 10:33 GMT+09:00 Thomas Munro : >> On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote: >>> Any opinions? >> >> The only reason I can think of for having it

Re: FP16 Support?

2017-11-14 10:33 GMT+09:00 Thomas Munro : > On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote: >> Any opinions? > > The only reason I can think of for having it in core is that you might > want to use standard SQL notation FLOAT(10) to refer

Re: FP16 Support?

2017-11-14 10:21 GMT+09:00 Tom Lane : > Kohei KaiGai writes: >> How about your thought for support of half-precision floating point, >> FP16 in short? > > This sounds like a whole lotta work for little if any gain. There's not > going to be any useful

Re: [HACKERS] A GUC to prevent leader processes from running subplans?

On Tue, Nov 14, 2017 at 10:30 AM, Robert Haas wrote: > On Sat, Nov 11, 2017 at 10:48 PM, Thomas Munro > wrote: >> How about parallel_leader_participation = on|off? The attached >> version has it that way, and adds regression tests to

Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 2:39 AM, Robert Haas wrote: > On Sat, Nov 11, 2017 at 7:19 AM, Amit Kapila wrote: >> I have tried to follow the practice we have used for param extern >> params (SerializeParamList is in params.c) and most of the handling of

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Hi, On 2017-11-03 07:53:30 -0700, Andres Freund wrote: > Here's that patch. I've stared at this some, and Robert did too. Robert > mentioned that the commit message might need some polish and I'm not > 100% sure about the error message texts yet. > > I'm not yet convinced that the new elog in

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Tue, Nov 14, 2017 at 10:48 AM, Peter Geoghegan wrote: > On Mon, Nov 13, 2017 at 5:07 PM, Masahiko Sawada > wrote: >>> I've been suspicious of that commit (and related commits) for a while >>> now [1]. I think that it explains a couple of different problem

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Tue, Nov 14, 2017 at 10:52 AM, Eric Lam wrote: > Please unsubscribe me. (Please do not hijack the threads) Help yourself: https://www.postgresql.org/community/lists/subscribe/ -- Michael

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

Hi, Please unsubscribe me. thanksEric On Tuesday, November 14, 2017, 2:02:04 AM GMT+8, Peter Geoghegan wrote: On Mon, Nov 13, 2017 at 12:25 AM, Masahiko Sawada wrote: > Commit e2c79e14 prevented multiple cleanup process for pending list in > GIN

Re: [HACKERS] GatherMerge misses to push target list

On Tue, Nov 14, 2017 at 3:08 AM, Robert Haas wrote: > On Sun, Nov 12, 2017 at 2:29 AM, Amit Kapila wrote: >> Agreed. Your change looks good to me. > > OK, committed. > Thank you. -- With Regards, Amit Kapila. EnterpriseDB:

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Mon, Nov 13, 2017 at 5:07 PM, Masahiko Sawada wrote: >> I've been suspicious of that commit (and related commits) for a while >> now [1]. I think that it explains a couple of different problem >> reports that we have seen. > > Yeah, the problem here is that vacuum and

Re: FP16 Support?

On Tue, Nov 14, 2017 at 1:11 PM, Kohei KaiGai wrote: > Any opinions? The only reason I can think of for having it in core is that you might want to use standard SQL notation FLOAT(10) to refer to it. Right now our parser converts that to float4 but it could map precisions

Re: FP16 Support?

On 2017-11-13 20:21:47 -0500, Tom Lane wrote: > Kohei KaiGai writes: > > How about your thought for support of half-precision floating point, > > FP16 in short? > > This sounds like a whole lotta work for little if any gain. There's not > going to be any useful performance

Re: FP16 Support?

Kohei KaiGai writes: > How about your thought for support of half-precision floating point, > FP16 in short? This sounds like a whole lotta work for little if any gain. There's not going to be any useful performance gain from using half-width floats except in an environment

Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted

On Tue, Nov 14, 2017 at 3:01 AM, Peter Geoghegan wrote: > On Mon, Nov 13, 2017 at 12:25 AM, Masahiko Sawada > wrote: >> Commit e2c79e14 prevented multiple cleanup process for pending list in >> GIN index. But I think that there is still possibility that

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

On Tue, Nov 14, 2017 at 6:50 AM, Tom Lane wrote: > Fabien COELHO writes: Note that if "c" is freed by "d" (drop), then it may be worth considering that "t" (table) could be replaced by "c" (create). > >>> I thought about that, but the argument

Re: [HACKERS] No mention of CREATE STATISTICS in event trigger docs

On 14 November 2017 at 07:39, Alvaro Herrera wrote: > David Rowley wrote: >> A patch to fix this is attached. > > Thanks, pushed. Thanks for pushing. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &

FP16 Support?

Hello, How about your thought for support of half-precision floating point, FP16 in short? https://en.wikipedia.org/wiki/Half-precision_floating-point_format Probably, it does not make sense for most of our known workloads. Our supported hardware platform does not support FP16 operations,

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On 11/13/17, 5:09 PM, "Tom Lane" wrote: > Michael Paquier writes: >> On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote: >>> Even if that's the case, I fail to see why it'd be a good idea to have >>> any sort of pg_upgrade

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Tue, Nov 14, 2017 at 7:32 AM, Andres Freund wrote: > On 2017-11-14 07:26:22 +0900, Michael Paquier wrote: >> On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund wrote: >> > Hm. I'm not really on-board with doing this in pg_upgrade. A more >> > logical place

Re: Typo in auth-scram.c

On Mon, Nov 13, 2017 at 10:37 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> auth-scram.c is visibly not able to do things in a deterministic way, >> that's more determinisitc: > > Hah, excellent point, will push in a moment (also to test

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Tue, Nov 14, 2017 at 6:11 AM, Andres Freund wrote: > Hm. I'm not really on-board with doing this in pg_upgrade. A more > logical place seems to be pg_resetwal or something - there's no need to > force a pg_upgrade cycle (which is pretty expensive on clusters with a >

Re: Migration to PGLister - After

Geoff Winkless writes: > The removal of the [HACKERS] (etc) header will be frustrating for me: I do > not sort mailing lists into folders (I simply scan the "Forums" autofilter > in gmail) and have no wish to do so, and there is no way to make such a > machine-readable header

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

Fabien COELHO writes: >>> Note that if "c" is freed by "d" (drop), then it may be worth considering >>> that "t" (table) could be replaced by "c" (create). >> I thought about that, but the argument that 'c' might mean different >> sorts of create steps (e.g. create index)

Re: [HACKERS] GatherMerge misses to push target list

On Sun, Nov 12, 2017 at 2:29 AM, Amit Kapila wrote: > Agreed. Your change looks good to me. OK, committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] pg_upgrade to clusters with a different WAL segment size

On Fri, Nov 10, 2017 at 4:04 PM, Michael Paquier wrote: > On Sat, Nov 11, 2017 at 12:46 AM, Bossart, Nathan wrote: >> Allowing changes to the WAL segment size during pg_upgrade seems like a >> nice way to avoid needing a dump and load, so I would

Re: [COMMITTERS] pgsql: Add hash partitioning.

On Mon, Nov 13, 2017 at 3:24 AM, amul sul wrote: > Updated patch attached -- Adjusted code comment to survive against pgindent. That's not the right fix, or at least it's not complete. You shouldn't call PG_GETARG_...(n) until you've verified that PG_ARGISNULL(n) returns

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

Note that if "c" is freed by "d" (drop), then it may be worth considering that "t" (table) could be replaced by "c" (create). I thought about that, but the argument that 'c' might mean different sorts of create steps (e.g. create index) seemed reasonable. I think we're best off leaving it

Re: Migration to PGLister - After

On Mon, Nov 13, 2017 at 4:41 PM, Geoff Winkless wrote: > The removal of the [HACKERS] (etc) header will be frustrating for me: I do > not sort mailing lists into folders (I simply scan the "Forums" autofilter > in gmail) and have no wish to do so, and there is no way to make

Re: Migration to PGLister - After

Hi, > Am 13.11.2017 um 14:14 schrieb Stephen Frost : > > The changes which we expect to be most significant to users can be found > on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce the > current version of which is also included below. Sorry, this is a

Re: Jsonb transform for pl/python

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Hi Anthony, Thank you for the new version of the patch!

Re: Migration to PGLister - After

Greetings, * Tatsuo Ishii (is...@sraoss.co.jp) wrote: > > This list has now been migrated to new mailing list software known as > > 'PGLister'. This migration will impact all users of this mailing list > > in one way or another. > > > > If you would like to unsubscribe from this mailing list,

Re: Migration to PGLister - After

From: Stephen Frost Subject: Migration to PGLister - After Date: Mon, 13 Nov 2017 08:14:56 -0500 Message-ID: <20171113131456.gf4...@tamriel.snowman.net> > Greetings! > > This list has now been migrated to new mailing list software known as > 'PGLister'. This migration will

Migration to PGLister - After

Greetings! This list has now been migrated to new mailing list software known as 'PGLister'. This migration will impact all users of this mailing list in one way or another. If you would like to unsubscribe from this mailing list, please click on 'Show Original' or 'Show Headers' in your client