Re: [HACKERS] A Modest Upgrade Proposal

On Sun, Jul 17, 2016 at 02:55:20PM -0400, Jan Wieck wrote: > On Sun, Jul 17, 2016 at 2:08 PM, Jim Nasby wrote: > > On 7/13/16 2:06 PM, Joshua D. Drake wrote: > >> On 07/07/2016 01:01 PM, Robert Haas wrote: > >> There was an unconference session on this topic at PGCon and

Re: [HACKERS] LWLocks in DSM memory

On Tue, Jul 26, 2016 at 6:00 AM, Andres Freund wrote: > I think the better fix here would acutally be to get rid of a pointer > based list here, and a) replace the queue with integer offsets ... Here is a prototype of that idea. It replaces that dlist with a proclist, a new

Re: [HACKERS] A Modest Upgrade Proposal

On Thu, Jul 28, 2016 at 10:22 AM, Craig Ringer wrote: > It might, actually. One approach for online upgrade is to: > > * pg_basebackup the master > * start the replica and let it catch up > * create a logical replication slot on the master > * replace the replication.conf

Re: [HACKERS] A Modest Upgrade Proposal

On 28 July 2016 at 04:35, Bruce Momjian wrote: > On Fri, Jul 8, 2016 at 12:18:28AM +0100, Simon Riggs wrote: > > On 7 July 2016 at 21:10, Robert Haas wrote: > > > > pg_upgrade does that, kinda. I'd like to have something better, but > > in the

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

> On 2016/07/27 13:51, Kouhei Kaigai wrote: > > This output is, at least, not incorrect. > > This ForeignScan actually scan a relation that consists of two joined > > tables on the remote side. So, not incorrect, but may not convenient for > > better understanding by users who don't have deep

Re: [HACKERS] old_snapshot_threshold allows heap:toast disagreement

Hi, On 2016-07-26 15:13:41 -0400, Robert Haas wrote: > On Thu, Jul 21, 2016 at 12:06 PM, Robert Haas wrote: > > On Wed, Jul 20, 2016 at 9:15 PM, Noah Misch wrote: > >> This PostgreSQL 9.6 open item now needs a permanent owner. Would any other > >>

Re: [HACKERS] Fixing target-column indirection in INSERT with multiple VALUES

Kevin Grittner writes: > On Wed, Jul 27, 2016 at 1:47 PM, Tom Lane wrote: >> this would require an initdb because it changes the >> representation of stored rules for cases like this, > So pg_upgrade would not work at all for the version this goes into,

Re: [HACKERS] Fixing target-column indirection in INSERT with multiple VALUES

On Wed, Jul 27, 2016 at 1:47 PM, Tom Lane wrote: > I looked into the problem reported in bug #14265, > attached is a proposed patch that fixes this bug > this would require an initdb because it changes the > representation of stored rules for cases like this, So pg_upgrade

Re: [HACKERS] Why we lost Uber as a user

On 07/26/2016 08:45 PM, Robert Haas wrote: > That's why I found Josh's restatement useful - I am assuming without > proof that his restatement is accurate FWIW, my restatement was based on some other sites rather than Uber. Including folks who didn't abandon Postgres. -- -- Josh Berkus Red

Re: [HACKERS] A Modest Upgrade Proposal

On Fri, Jul 8, 2016 at 12:18:28AM +0100, Simon Riggs wrote: > On 7 July 2016 at 21:10, Robert Haas wrote: > > pg_upgrade does that, kinda.  I'd like to have something better, but > in the absence of that, I think it's quite wrong to think about > deprecating

Re: [HACKERS] Rethinking TupleTableSlot deforming

Andres Freund wrote: > Hi, > > I've previously mentioned (e.g. [1]) that tuple deforming is a serious > bottlneck. I've also experimented successfully [2] making > slot_deform_tuple() faster. I'm currently messing with making heapam.c be just one possible implementation of tuple storage, to

[HACKERS] Fixing target-column indirection in INSERT with multiple VALUES

I looked into the problem reported in bug #14265, https://www.postgresql.org/message-id/20160727005725.7438.26...@wrigleys.postgresql.org The core of the problem is a design decision that seems pretty bad in hindsight: if we have array-subscripting or field-selection decoration in the target

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

On 2016-07-27 10:04:52 -0400, Robert Haas wrote: > On Tue, Jul 26, 2016 at 8:43 PM, Andres Freund wrote: > > As previously mentioned, dynahash isn't particularly fast. In many cases > > that doesn't particularly matter. But e.g. hash aggregation and bitmap > > index scans are

Re: [HACKERS] [PATCH v12] GSSAPI encryption support

Michael Paquier writes: > On Wed, Jul 27, 2016 at 12:22 AM, Robbie Harwood wrote: >> Michael Paquier writes: >> >> So there's a connection setting `sslmode` that we'll want something >> similar to here (`gssapimode` or

Re: [HACKERS] Why we lost Uber as a user

On Wed, Jul 27, 2016 at 08:33:52AM -0500, Merlin Moncure wrote: > > Or in short, this seems like an annoyance, not a time-for-a-new-database > > kind of problem. > > Well, the real annoyance as I understand it is the raw volume of bytes > of WAL traffic a single update of a field can cause. They

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Tue, Jul 26, 2016 at 6:15 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/26/16 6:14 PM, Vik Fearing wrote: > > As mentioned elsewhere in the thread, you can just do WHERE true to get > > around it, so why on Earth have it PGC_SUSET? > > I'm not sure whether it's

Re: [HACKERS] [Patch] RBTree iteration interface improvement

And as always, I didn't re-check a patch before sending it :) Here is a corrected version without any fprintf's. -- Best regards, Aleksander Alekseev diff --git a/src/backend/access/gin/ginbulk.c b/src/backend/access/gin/ginbulk.c index d6422ea..eac76c4 100644 ---

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

Robert Haas writes: > On Mon, Jul 25, 2016 at 6:04 PM, Tom Lane wrote: >> I suppose that a fix based on putting PG_TRY blocks into all the affected >> functions might be simple enough that we'd risk back-patching it, but >> I don't really want to go

[HACKERS] [Patch] RBTree iteration interface improvement

Hello While working on some new feature for PostgreSQL (which is still in development and is irrelevant in this context) I noticed that current RBTree implementation interface is following: ``` extern void rb_begin_iterate(RBTree *rb, RBOrderControl ctrl); extern RBNode *rb_iterate(RBTree *rb);

Re: [HACKERS] copyParamList

On Wed, Jul 27, 2016 at 10:09 AM, Amit Kapila wrote: > On Wed, Jul 27, 2016 at 6:46 PM, Robert Haas wrote: >> On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote: >>> Okay, that makes sense to me apart from minor issue

Re: [HACKERS] [PROPOSAL] Temporal query processing with range types

On Fri, Jul 22, 2016 at 7:15 AM, Anton Dignös wrote: > We would like to contribute to PostgreSQL a solution that supports the query > processing of "at each time point". The basic idea is to offer two new > operators, NORMALIZE and ALIGN, whose purpose is to adjust (or

Re: [HACKERS] copyParamList

On Wed, Jul 27, 2016 at 6:46 PM, Robert Haas wrote: > On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote: >> Okay, that makes sense to me apart from minor issue reported by >> Andrew. I think we might want to slightly rephrase the comments on >>

Re: [HACKERS] Macro customizable hashtable / bitmapscan & aggregation perf

On Tue, Jul 26, 2016 at 8:43 PM, Andres Freund wrote: > As previously mentioned, dynahash isn't particularly fast. In many cases > that doesn't particularly matter. But e.g. hash aggregation and bitmap > index scans are quite sensitive to hash performance. > > The biggest

Re: [HACKERS] No longer possible to query catalogs for index capabilities?

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Yeah. I'm not very impressed by the underlying assumption that it's >> okay for client-side code to hard-wire knowledge about what indoption >> bits mean, but not okay for it to hard-wire knowledge about which

Re: [HACKERS] Why we lost Uber as a user

On Tue, Jul 26, 2016 at 5:07 PM, Tom Lane wrote: > Josh Berkus writes: >> To explain this in concrete terms, which the blog post does not: > >> 1. Create a small table, but one with enough rows that indexes make >> sense (say 50,000 rows). > >> 2. Make this

Re: [HACKERS] copyParamList

On Wed, Jul 27, 2016 at 2:20 AM, Amit Kapila wrote: > Okay, that makes sense to me apart from minor issue reported by > Andrew. I think we might want to slightly rephrase the comments on > top of copyParamList() which indicates only about dynamic parameter > hooks. I

Re: [HACKERS] copyParamList

On Wed, Jul 27, 2016 at 12:25 AM, Andrew Gierth wrote: >> "Robert" == Robert Haas writes: > Robert> So I think we instead ought to fix it as in the attached. > > Robert>if (retval->paramMask != NULL && > Robert> -

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On 27/07/16 06:11, David Fetter wrote: > On Wed, Jul 27, 2016 at 03:24:28AM +0200, Vik Fearing wrote: >> On 27/07/16 03:15, Peter Eisentraut wrote: >>> On 7/26/16 6:14 PM, Vik Fearing wrote: As mentioned elsewhere in the thread, you can just do WHERE true to get around it, so why on

Re: [HACKERS] MSVC pl-perl error message is not verbose enough

On Tue, Jul 26, 2016 at 9:44 PM, Michael Paquier wrote: > On Wed, Jul 27, 2016 at 12:41 AM, John Harvey > wrote: > > Because of this, I've submitted a small patch which fixes the verbosity > of > > the error message to actually explain

Re: [HACKERS] Why we lost Uber as a user

On 27/07/16 05:45, Robert Haas wrote: > On Tue, Jul 26, 2016 at 8:27 PM, Stephen Frost wrote: >> * Joshua D. Drake (j...@commandprompt.com) wrote: >>> Hello, >>> >>> The following article is a very good look at some of our limitations >>> and highlights some of the pains many

Re: [HACKERS] Optimizing numeric SUM() aggregate

Andrew Borodin writes: >> I don't think there is any reason for this new code to assume NBASE=1 > There is a comment on line 64 stating that value 1 is hardcoded > somewhere else, any other value is not recommended and a bunch of code > is left for historical

Re: [HACKERS] handling unconvertible error messages

On 25 July 2016 at 22:43, Peter Eisentraut wrote: > Example: I have a database cluster initialized with --locale=ru_RU.UTF-8 > (built with NLS). Let's say for some reason, I have client encoding set > to LATIN1. All error messages come back like this: > >

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 10:17, Andrew Borodin wrote: >> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1)) > Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX > / NBASE for any NBASE > 1 Interesting. I think it's clearer the way it is in

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 09:57, Dean Rasheed wrote: > it could be > coded using something like > > accum->maxdig += NBASE - 1; > if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1)) > Propagate carries... > Oops, that's not quite right because maxdig

Re: [HACKERS] Optimizing numeric SUM() aggregate

> if (accum->maxdig > (INT_MAX - INT_MAX / NBASE) / (NBASE - 1)) Woth noting that (INT_MAX - INT_MAX / NBASE) / (NBASE - 1) == INT_MAX / NBASE for any NBASE > 1 >I don't think there is any reason for this new code to assume NBASE=1 There is a comment on line 64 stating that value 1 is

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/07/27 13:51, Kouhei Kaigai wrote: This output is, at least, not incorrect. This ForeignScan actually scan a relation that consists of two joined tables on the remote side. So, not incorrect, but may not convenient for better understanding by users who don't have deep internal knowledge.

Re: [HACKERS] Optimizing numeric SUM() aggregate

On 27 July 2016 at 07:33, Andrew Borodin wrote: >>I think we could do carry every 0x7FF / 1 accumulation, couldn't we? > > I feel that I have to elaborate a bit. Probably my calculations are wrong. > > Lets assume we already have accumulated INT_MAX of digits in

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/07/27 13:09, Ashutosh Bapat wrote: The patch always prints ForeignJoin when scanrelid <= 0, which would be odd considering that FDWs can now push down post-join operations. We need to device a better way to convey post-join operations. May be something like Foreign Grouping, aggregation

Re: [HACKERS] Optimizing numeric SUM() aggregate

>I think we could do carry every 0x7FF / 1 accumulation, couldn't we? I feel that I have to elaborate a bit. Probably my calculations are wrong. Lets assume we already have accumulated INT_MAX of digits in previous-place accumulator. That's almost overflow, but that's not overflow.

Re: [HACKERS] pg_dumping extensions having sequences with 9.6beta3

On Wed, Jul 27, 2016 at 8:07 AM, Stephen Frost wrote: > That'd be great. It's definitely on my list of things to look into, but > I'm extremely busy this week. I hope to look into it on Friday, would > be great to see what you find. Sequences that are directly defined in

Re: [HACKERS] copyParamList

On Wed, Jul 27, 2016 at 2:03 AM, Robert Haas wrote: > On Fri, Jul 8, 2016 at 2:28 AM, Amit Kapila wrote: >> On Tue, May 31, 2016 at 10:10 PM, Robert Haas wrote: >>> On Fri, May 27, 2016 at 6:07 PM, Andrew Gierth >>>