Re: [HACKERS] On partitioning

On Thu, Dec 11, 2014 at 8:42 PM, Robert Haas wrote: > > On Thu, Dec 11, 2014 at 12:00 AM, Amit Kapila wrote: > > Yeah either this way or what Josh has suggested upthread, the main > > point was that if at all we want to support multi-column list partitioning > > then we need to have slightly diff

Re: [HACKERS] On partitioning

> -Original Message- > From: Robert Haas [mailto:robertmh...@gmail.com] > On Thu, Dec 11, 2014 at 12:00 AM, Amit Kapila > wrote: > > Yeah either this way or what Josh has suggested upthread, the main > > point was that if at all we want to support multi-column list partitioning > > then w

Re: [HACKERS] Compression of full-page-writes

On Tue, Dec 9, 2014 at 4:09 AM, Robert Haas wrote: > > On Sun, Dec 7, 2014 at 9:30 PM, Simon Riggs wrote: > > * parameter should be SUSET - it doesn't *need* to be set only at > > server start since all records are independent of each other > > Why not USERSET? There's no point in trying to proh

Re: [HACKERS] Turning off HOT/Cleanup sometimes

On 17 November 2014 at 22:08, Simon Riggs wrote: > On 17 November 2014 21:09, Alvaro Herrera wrote: >> What happened to this patch? I'm going over something that could use >> the concept of "clean some stuff up when reading this page, but only if >> we're already writing" or similar. >> >> I see

[HACKERS] pg_regress writes into source tree

When using a vpath build pg_regress writes the processed input/*.source files into the *source* tree, which isn't supposed to happen. This appears to be a thinko introduced in this patch: e3fc4a97bc8ee82a78605b5ffe79bd4cf3c6213b The attached patch fixes it. diff --git a/src/test/regress/pg_regres

Re: [HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

(2014/12/12 11:19), Tom Lane wrote: > Etsuro Fujita writes: >> (2014/12/12 10:37), Tom Lane wrote: >>> Yeah, this is clearly a thinko: really, nothing in the planner should >>> be using get_parse_rowmark(). I looked around for other errors of the >>> same type and found that postgresGetForeignPla

Re: [HACKERS] Review of Refactoring code for sync node detection

On Thu, Dec 11, 2014 at 10:07 PM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > * I don't like filling the priorities-array in > SyncRepGetSynchronousStandby(). It might be convenient for the one caller > that needs it, but it seems pretty ad hoc. > > In fact, I don't really see the point

Re: [HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

Etsuro Fujita writes: > (2014/12/12 10:37), Tom Lane wrote: >> Yeah, this is clearly a thinko: really, nothing in the planner should >> be using get_parse_rowmark(). I looked around for other errors of the >> same type and found that postgresGetForeignPlan() is also using >> get_parse_rowmark().

Re: [HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

(2014/12/12 10:37), Tom Lane wrote: > Yeah, this is clearly a thinko: really, nothing in the planner should > be using get_parse_rowmark(). I looked around for other errors of the > same type and found that postgresGetForeignPlan() is also using > get_parse_rowmark(). While that's harmless at the

Re: [HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

Kyotaro HORIGUCHI writes: > This is caused by that IndexRecheck examines the test tuple with > a qual "c = '0'" without "b IN ('0', '1')". The part has been > removed in create_indexscan_plan. It decieds whether to remove a > qual or not using get_parse_rowmark(root->parse(->rowMarks)) and > predi

Re: [HACKERS] double vacuum in initdb

On 12/11/14 11:44 AM, Kevin Grittner wrote: > We want to finish with VACUUM FREEZE without the FULL, unless we > don't care about missing visibility maps and free space maps. Why would we care, and if we do, why does VACUUM FULL remove them? You can also run plain VACUUM after FULL to put the map

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Fri, Dec 12, 2014 at 10:19 AM, Simon Riggs wrote: > > On 11 December 2014 at 23:41, Michael Paquier > wrote: > > > Glad that things are in order now. I have nothing else left to complain > > about with this feature. Thanks. > > I think you've discovered a new meaning of Ready for Committer > Y

Re: [HACKERS] [Bug] Duplicate results for inheritance and FOR UPDATE.

Hello, > > This issue is that some query returns duplicate rows after FOR > > UPDATE was blocked, in other words, after getting > > HeapTupleUpdated in ExecLockRows. > > Good catch! Thank you. > > In the EPQ block in ExecScanFetch, it seems should return NULL if > > the relation does not has te

Re: [HACKERS] Proposal : REINDEX SCHEMA

On 11 December 2014 at 23:41, Michael Paquier wrote: > Glad that things are in order now. I have nothing else left to complain > about with this feature. Thanks. I think you've discovered a new meaning of Ready for Committer -- Simon Riggs http://www.2ndQuadrant.com/ Postgr

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Fri, Dec 12, 2014 at 8:41 AM, Michael Paquier wrote: > On Fri, Dec 12, 2014 at 8:00 AM, Simon Riggs > wrote: > >> Rather unluckily that seems to have coincided with Tom's changes, so >> I've only added the bits that have nothing to do with Tom's changes - >> all of which stand. >> > Glad that

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Fri, Dec 12, 2014 at 1:34 AM, Bruce Momjian wrote: > On Thu, Dec 11, 2014 at 01:26:38PM +0530, Rahila Syed wrote: > > >I am sorry but I can't understand the above results due to wrapping. > > >Are you saying compression was twice as slow? > > > > CPU usage at user level (in seconds) for compr

Re: [HACKERS] [Bug] Duplicate results for inheritance and FOR UPDATE.

Kyotaro HORIGUCHI writes: > This issue is that some query returns duplicate rows after FOR > UPDATE was blocked, in other words, after getting > HeapTupleUpdated in ExecLockRows. Good catch! > In the EPQ block in ExecScanFetch, it seems should return NULL if > the relation does not has test tupl

Re: [HACKERS] Proposal : REINDEX SCHEMA

On Fri, Dec 12, 2014 at 8:00 AM, Simon Riggs wrote: > On 9 December 2014 at 12:21, Michael Paquier > wrote: > > On Tue, Dec 9, 2014 at 6:43 PM, Michael Paquier > > wrote: > >> OK. Perhaps that's not worth mentioning in the release notes, but some > >> users may be used to the old behavior. What

Re: [HACKERS] Commitfest problems

On Fri, Dec 12, 2014 at 7:55 AM, Tom Lane wrote: > Josh Berkus writes: > > How about *you* run the next one, Tom? > > I think the limited amount of time I can put into a commitfest is better > spent on reviewing patches than on managing the process. > That's not only your case, I have the same f

Re: [HACKERS] Commitfest problems

On Fri, Dec 12, 2014 at 7:27 AM, Josh Berkus wrote: > On 12/11/2014 02:12 PM, Tom Lane wrote: > > Josh Berkus writes: > >> While the CFs are still doing (1), support for (2) ended sometime in the > >> 9.3 development cycle. Partly this is because current CFMs are not > >> permitted to take auth

Re: [HACKERS] Final Patch for GROUPING SETS

> "Tom" == Tom Lane writes: >> What that code does is produce plans that look like this: >> GroupAggregate >> -> Sort >>-> ChainAggregate >> -> Sort >> -> ChainAggregate >> in much the same way that WindowAgg nodes are generated. Tom> That seems pretty messy, esp

Re: [HACKERS] Proposal : REINDEX SCHEMA

On 9 December 2014 at 12:21, Michael Paquier wrote: > On Tue, Dec 9, 2014 at 6:43 PM, Michael Paquier > wrote: >> OK. Perhaps that's not worth mentioning in the release notes, but some >> users may be used to the old behavior. What about the other issues >> (regression test for permissions incorr

Re: [HACKERS] Commitfest problems

Josh Berkus writes: > How about *you* run the next one, Tom? I think the limited amount of time I can put into a commitfest is better spent on reviewing patches than on managing the process. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching

On 11.12.2014 22:16, Robert Haas wrote: > On Thu, Dec 11, 2014 at 2:51 PM, Tomas Vondra wrote: >> No, it's not rescanned. It's scanned only once (for the batch #0), and >> tuples belonging to the other batches are stored in files. If the number >> of batches needs to be increased (e.g. because of

Re: [HACKERS] Commitfest problems

On 12/11/2014 02:12 PM, Tom Lane wrote: > Josh Berkus writes: >> While the CFs are still doing (1), support for (2) ended sometime in the >> 9.3 development cycle. Partly this is because current CFMs are not >> permitted to take authoritative steps to ensure that the CF ends on >> time, and partl

Re: [HACKERS] Commitfest problems

Josh Berkus writes: > Well, the CF process was added for 2 reasons: > 1) We were losing track of some patches until integration time, when > Bruce suddently found them in the -hackers archives. > 2) In order to give the senior committers some time *off* from reviewing > other people's patches.

Re: [HACKERS] Commitfest problems

On Thu, Dec 11, 2014 at 1:07 PM, Bruce Momjian wrote: >> As far as I'm concerned, we might as well just have one commitfest per >> major release. Call it a patch list. Make the list sortable by created >> date and last-updated date, and let the system police itself. At least >> that's honest. >

Re: [HACKERS] Commitfest problems

On 12/11/2014 01:52 PM, Alvaro Herrera wrote: > Bruce Momjian wrote: >> On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote: > >>> Actually, to me it sounds a lot like what we did 10 years ago before >>> the commitfests except with a way to track the patches (other than the >>> mail archive

Re: [HACKERS] Commitfest problems

Peter Eisentraut-2 wrote > On 12/11/14 1:35 AM, Bruce Momjian wrote: >> I have heard repeated concerns about the commitfest process in the past >> few months. The fact we have been in a continual commitfest since >> August also is concerning. > > I realized the other day, I'm embracing the idea o

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 1:49 PM, Alvaro Herrera wrote: > Review is good, but (as history shows) some bugs can slip through even > extensive review such as the one multixacts got from Noah and Andres. > Had anyone put some real stress on the beta, we could have noticed some > of these bugs much ear

Re: [HACKERS] Commitfest problems

Bruce Momjian wrote: > On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote: > > Actually, to me it sounds a lot like what we did 10 years ago before > > the commitfests except with a way to track the patches (other than the > > mail archives) and more people participating in patch reviews.

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

FWIW I don't think any amount of process would have gotten multixact to not have the copious bugs it had. It was just too complex a patch, doing ugly things to parts too deeply linked to the inner guts of the server. We might have spared a few with some extra testing (such as the idiotic wraparou

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

On Thu, Dec 11, 2014 at 01:25:00PM -0800, Mark Dilger wrote: > > > On Thu, Dec 11, 2014 at 12:12 PM, Tom Lane wrote: > > Mark Dilger writes: > > The attached patch changes the type of chunk_seq to int32, > > rather than changing the %d formatting.  The other changes > > are the

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

I spoke too soon. Actually, the Oid definition is in src/include/postgres_ext.h, which I'm sure you all know. But I'm changing other typedefs too, not just for Oid. I've been going through a copy of the code and replacing int32 and uint32 with the appropriate type such as Oid, TransactionId, and

Re: [HACKERS] Commitfest problems

On Thu, Dec 11, 2014 at 01:12:30PM -0800, Joe Conway wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/11/2014 01:07 PM, Bruce Momjian wrote: > > On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote: > >> On 12/11/14 1:35 AM, Bruce Momjian wrote: > >>> I have heard rep

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Dec 11, 2014 at 1:11 AM, Peter Geoghegan wrote: > On Mon, Dec 8, 2014 at 8:16 PM, Peter Geoghegan wrote: >> Attached revision, v1.6, slightly tweaks the ordering of per-statement >> trigger execution. > > Right now, there is no way for a before row insert/update trigger to > determine whe

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 2:05 PM, Bruce Momjian wrote: > On Thu, Dec 11, 2014 at 10:04:43AM -0700, David G Johnston wrote: > > Tom Lane-2 wrote > > > Robert Haas < > > > > > robertmhaas@ > > > > > > writes: > > >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus < > > > > > josh@ > > > > > > wrote: >

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

On Thu, Dec 11, 2014 at 12:12 PM, Tom Lane wrote: > Mark Dilger writes: > > The attached patch changes the type of chunk_seq to int32, > > rather than changing the %d formatting. The other changes > > are the same as in the previous patch. > > BTW, how are you finding these? If it's some autom

Re: [HACKERS] PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching

On Thu, Dec 11, 2014 at 2:51 PM, Tomas Vondra wrote: > No, it's not rescanned. It's scanned only once (for the batch #0), and > tuples belonging to the other batches are stored in files. If the number > of batches needs to be increased (e.g. because of incorrect estimate of > the inner table), the

Re: [HACKERS] Commitfest problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/11/2014 01:07 PM, Bruce Momjian wrote: > On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote: >> On 12/11/14 1:35 AM, Bruce Momjian wrote: >>> I have heard repeated concerns about the commitfest process in >>> the past few months. T

Re: [HACKERS] Commitfest problems

On Thu, Dec 11, 2014 at 03:47:29PM -0500, Peter Eisentraut wrote: > On 12/11/14 1:35 AM, Bruce Momjian wrote: > > I have heard repeated concerns about the commitfest process in the past > > few months. The fact we have been in a continual commitfest since > > August also is concerning. > > I real

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 10:04:43AM -0700, David G Johnston wrote: > Tom Lane-2 wrote > > Robert Haas < > > > robertmhaas@ > > > > writes: > >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus < > > > josh@ > > > > wrote: > >>> While there were technical > >>> issues, 9.4 dragged a considerable amou

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 3:47 PM, Jeff Janes wrote: > I agree. Having your patch disappear into the void is not friendly at all. > But I don't think a commentless "-1" is the answer, either. That might one > of the few things worse than silence. Even if the comment is just "This > seems awfully

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 11:40 AM, Heikki Linnakangas < hlinnakan...@vmware.com> wrote: > On 12/11/2014 08:51 PM, Josh Berkus wrote: > >> On 12/11/2014 09:22 AM, Heikki Linnakangas wrote: >> >> >>> Perhaps we should change the process so that it is the patch author's >>> responsibility to find a r

Re: [HACKERS] Commitfest problems

On 12/11/14 1:35 AM, Bruce Momjian wrote: > I have heard repeated concerns about the commitfest process in the past > few months. The fact we have been in a continual commitfest since > August also is concerning. I realized the other day, I'm embracing the idea of a continual commitfest. I'm sti

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

Tom Lane wrote: > Mark Dilger writes: > > The attached patch changes the type of chunk_seq to int32, > > rather than changing the %d formatting. The other changes > > are the same as in the previous patch. > > BTW, how are you finding these? If it's some automated tool, what? > (If you're findi

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 11:59:58AM -0500, Robert Haas wrote: > The problem is that, on the one hand, we have a number of serious > problems with things that got committed and turned out to have > problems - the multixact stuff, and JSONB, in particular - and on the > other hand, we are lacking in a

Re: [HACKERS] Commitfest problems

On 12/11/14 1:56 PM, Robert Haas wrote: > I feel like there's increasingly not that much easy stuff left to do. > Many of the problems we haven't solved yet are unsolved because they > are really hard, or because not that important, or both. You know, I was telling people the very same thing in 20

Re: [HACKERS] 9.5: Memory-bounded HashAgg

On 11.12.2014 11:46, Jeff Davis wrote: > > New patch attached. All open items are complete, though the patch may > have a few rough edges. > > Summary of changes: > > * rebased on top of latest memory accounting patch > http://www.postgresql.org/message-id/1417497257.5584.5.camel@jeff-desktop >

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

Mark Dilger writes: > The attached patch changes the type of chunk_seq to int32, > rather than changing the %d formatting. The other changes > are the same as in the previous patch. BTW, how are you finding these? If it's some automated tool, what? (If you're finding them by hand, I'm in awe of

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

Peter Geoghegan wrote: > On Thu, Dec 11, 2014 at 11:52 AM, Alvaro Herrera > wrote: > >> The problem with that is that we'll have a hard time to find volunteers for > >> that. But we only need to find one sucker for each commitfest. I can > >> volunteer to do that once a year; if the other active c

Re: [HACKERS] WIP: multivariate statistics / proof of concept

On 11.12.2014 17:53, Heikki Linnakangas wrote: > On 10/13/2014 01:00 AM, Tomas Vondra wrote: >> Hi, >> >> attached is a WIP patch implementing multivariate statistics. > > Great! Really glad to see you working on this. > >> + * FIXME This sample sizing is mostly OK when computing stats for >>

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 10:43 AM, Robert Haas wrote: >> Version 1.0 of INSERT ... ON CONFLICT UPDATE was posted in August - >> when development launched. It still doesn't have a reviewer, and it >> isn't actually in evidence that someone else has so much as downloaded >> and applied the patch > I

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 11:52 AM, Alvaro Herrera wrote: >> The problem with that is that we'll have a hard time to find volunteers for >> that. But we only need to find one sucker for each commitfest. I can >> volunteer to do that once a year; if the other active committers do the >> same, we're c

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

Heikki Linnakangas wrote: > That's one thought. Robert said the same thing about when he was the > commitfest manager; he just reviewed most the patches himself in the end. > And you mentioned that Tom used to review 70% of all incoming patches. How > about we make that official? It's the commitfe

Re: [HACKERS] PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching

On 11.12.2014 20:00, Robert Haas wrote: > On Thu, Dec 11, 2014 at 12:29 PM, Kevin Grittner wrote: >> >> Under what conditions do you see the inner side get loaded into the >> hash table multiple times? > > Huh, interesting. I guess I was thinking that the inner side got > rescanned for each new

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On 12/11/2014 08:51 PM, Josh Berkus wrote: On 12/11/2014 09:22 AM, Heikki Linnakangas wrote: I imagine that it's the same for everyone else. Many of the patches that sit in the commitfest for weeks are patches that no-one really cares much about. I'm not sure what to do about that. It would be

Re: [HACKERS] Final Patch for GROUPING SETS

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I've not spent any real effort looking at gsp2.patch yet, but it > Tom> seems even worse off comment-wise: if there's any explanation in > Tom> there at all of what a "chained aggregate" is, I didn't find it. > (Maybe "stacked" would ha

Re: [HACKERS] Commitfest problems

On Thu, Dec 11, 2014 at 11:49:43AM -0500, Peter Eisentraut wrote: > On 12/11/14 1:35 AM, Bruce Momjian wrote: > > While the commitfest process hasn't changed much and was very successful > > in the first few years, a few things have changed externally: > > > > 1 more new developers involved i

Re: [HACKERS] PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching

On Thu, Dec 11, 2014 at 12:29 PM, Kevin Grittner wrote: > Robert Haas wrote: >> On Sat, Dec 6, 2014 at 10:08 PM, Tomas Vondra wrote: >>>select a.i, b.i from a join b on (a.i = b.i); >> >> I think the concern is that the inner side might be something more >> elaborate than a plain table scan,

Re: [HACKERS] Commitfest problems

On Thu, Dec 11, 2014 at 1:26 PM, Josh Berkus wrote: > No, it's not a jump up by 2X, but it is an upwards trend. And I think > that Tom has it right that the additional patches we're seeing are > additional large, complex patches. I feel like there's increasingly not that much easy stuff left to

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On 12/11/2014 08:59 AM, Tom Lane wrote: > More abstractly, there's a lot of value in having a predictable release > schedule. That's going to mean that some release cycles are thin on > user-visible features, even if just as much work went into them. It's > the nature of the game. + 1,000,000 fr

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On 12/11/2014 09:22 AM, Heikki Linnakangas wrote: > I imagine that it's the same for everyone else. Many of the patches that > sit in the commitfest for weeks are patches that no-one really cares > much about. I'm not sure what to do about that. It would be harsh to > reject a patch just because n

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 1:06 PM, Peter Geoghegan wrote: > On Thu, Dec 11, 2014 at 7:37 AM, Robert Haas wrote: >> 2. It's not clear that we're going to have a particularly-impressive >> list of major features for 9.5. So far we've got RLS and BRIN. I >> expect that GROUPING SETS is far enough alo

Re: [HACKERS] Commitfest problems

On 12/11/2014 09:02 AM, Tom Lane wrote: > Peter Eisentraut writes: >> On 12/11/14 1:35 AM, Bruce Momjian wrote: >>> While the commitfest process hasn't changed much and was very successful >>> in the first few years, a few things have changed externally: >>> >>> 1 more new developers involved in

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

Thank you Alvaro, The attached patch changes the type of chunk_seq to int32, rather than changing the %d formatting. The other changes are the same as in the previous patch. Mark Dilger On Thu, Dec 11, 2014 at 9:39 AM, Alvaro Herrera wrote: > Mark Dilger wrote: > > I found a few places in t

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 8:03 AM, Tom Lane wrote: > > 2. The amount of pre-release testing we get from people outside the > hard-core development crowd seems to be continuing to decrease. > We were fortunate that somebody found the JSONB issue before it was > too late to do anything about it. Per

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 7:37 AM, Robert Haas wrote: > 2. It's not clear that we're going to have a particularly-impressive > list of major features for 9.5. So far we've got RLS and BRIN. I > expect that GROUPING SETS is far enough along that it should be > possible to get it in before developmen

Re: [HACKERS] WIP patch for Oid formatting in printf/elog strings

Mark Dilger wrote: > I found a few places in the code where a variable of > type Oid is printed using "%d" rather than "%u" and > changed them in the attached patch. > > In src/backend/replication/logical/reorderbuffer.c, > circa line 2494, chunk_seq is of type Oid, but > ent->last_chunk_seq is of

[HACKERS] WIP patch for Oid formatting in printf/elog strings

I found a few places in the code where a variable of type Oid is printed using "%d" rather than "%u" and changed them in the attached patch. In src/backend/replication/logical/reorderbuffer.c, circa line 2494, chunk_seq is of type Oid, but ent->last_chunk_seq is of type int32, leading me to questi

Re: [HACKERS] PATCH: hashjoin - gracefully increasing NTUP_PER_BUCKET instead of batching

Robert Haas wrote: > On Sat, Dec 6, 2014 at 10:08 PM, Tomas Vondra wrote: >>select a.i, b.i from a join b on (a.i = b.i); > > I think the concern is that the inner side might be something more > elaborate than a plain table scan, like an aggregate or join. I might > be all wet, but my impres

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On 12/11/2014 06:59 PM, Robert Haas wrote: On Thu, Dec 11, 2014 at 11:03 AM, Tom Lane wrote: I think 9.4 dragged almost entirely because of one issue: the compressibility of JSONB. Meh. While we certainly weren't very speedy about resolving that, I don't think that issue deserves all or even

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

David G Johnston wrote > > Tom Lane-2 wrote >> Robert Haas < >> robertmhaas@ >> > writes: >>> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus < >> josh@ >> > wrote: While there were technical issues, 9.4 dragged a considerable amount because most people were ignoring it in favor of

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

Tom Lane-2 wrote > Robert Haas < > robertmhaas@ > > writes: >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus < > josh@ > > wrote: >>> While there were technical >>> issues, 9.4 dragged a considerable amount because most people were >>> ignoring it in favor of 9.5 development. > >> I think 9.4 d

Re: [HACKERS] Commitfest problems

Peter Eisentraut writes: > On 12/11/14 1:35 AM, Bruce Momjian wrote: >> While the commitfest process hasn't changed much and was very successful >> in the first few years, a few things have changed externally: >> >> 1 more new developers involved in contributing small patches >> 2 more full-tim

Re: [HACKERS] double vacuum in initdb

On Thu, Dec 11, 2014 at 11:44 AM, Kevin Grittner wrote: > We want to finish with VACUUM FREEZE without the FULL, unless we > don't care about missing visibility maps and free space maps. Oh, good point. I had forgotten about that issue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 11:03 AM, Tom Lane wrote: >> I think 9.4 dragged almost entirely because of one issue: the >> compressibility of JSONB. > > Meh. While we certainly weren't very speedy about resolving that, > I don't think that issue deserves all or even most of the blame. > I agree with J

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

Bruce Momjian writes: > On Thu, Dec 11, 2014 at 10:37:32AM -0500, Robert Haas wrote: >> 2. It's not clear that we're going to have a particularly-impressive >> list of major features for 9.5. > How bad is the 9.5 feature list going to be compared to the 9.4 one that > had JSONB, but also a lot of

Re: [HACKERS] WIP: multivariate statistics / proof of concept

On 10/13/2014 01:00 AM, Tomas Vondra wrote: Hi, attached is a WIP patch implementing multivariate statistics. Great! Really glad to see you working on this. +* FIXME This sample sizing is mostly OK when computing stats for +* individual columns, but when computing multi

Re: [HACKERS] Commitfest problems

On 12/11/14 1:35 AM, Bruce Momjian wrote: > While the commitfest process hasn't changed much and was very successful > in the first few years, a few things have changed externally: > > 1 more new developers involved in contributing small patches > 2 more full-time developers creating

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 10:37:32AM -0500, Robert Haas wrote: > 2. It's not clear that we're going to have a particularly-impressive > list of major features for 9.5. So far we've got RLS and BRIN. I > expect that GROUPING SETS is far enough along that it should be > possible to get it in before de

Re: [HACKERS] double vacuum in initdb

Tom Lane wrote: > I think we could go to > PG_CMD_PUTS("ANALYZE;\nVACUUM FULL FREEZE;\n"); > > without any degradation of the intended results. > > Another idea would be to drop the FULL part and make this > > PG_CMD_PUTS("ANALYZE;\nVACUUM FREEZE;\n"); We want to finish with VACUUM FREEZE withou

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Dec 11, 2014 at 01:26:38PM +0530, Rahila Syed wrote: > >I am sorry but I can't understand the above results due to wrapping. > >Are you saying compression was twice as slow? > > CPU usage at user level (in seconds)  for compression set 'on' is 562 secs > while that for compression  set 'of

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

Robert Haas writes: > On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus wrote: >> While there were technical >> issues, 9.4 dragged a considerable amount because most people were >> ignoring it in favor of 9.5 development. > I think 9.4 dragged almost entirely because of one issue: the > compressibil

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus wrote: > While there were technical > issues, 9.4 dragged a considerable amount because most people were > ignoring it in favor of 9.5 development. I think 9.4 dragged almost entirely because of one issue: the compressibility of JSONB. And it became p

Re: [HACKERS] 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 12:35 AM, Tom Lane wrote: > Quite. So, here's a new thread. > > MHO is that, although 9.4 has slipped more than any of us would like, > 9.5 development launched right on time in August. So I don't see a > good reason to postpone 9.5 release just because 9.4 has slipped. >

Re: [HACKERS] SSL information view

Magnus Hagander writes: >> >> You should add it to the next CF for proper tracking, there are already many >> patches in the queue waiting for reviews :) > > Absolutely - I just wanted those that were already involved in the > thread to get a chance to look at it early :) didn't want to submit it

Re: [HACKERS] GSSAPI, SSPI - include_realm default

On Wed, Dec 10, 2014 at 4:53 AM, Bruce Momjian wrote: > On Tue, Dec 9, 2014 at 05:40:35PM -0500, Stephen Frost wrote: >> > I thought the idea was to backpatch documentation saying "it's a good idea >> > to change this value to x because of y". Not actually referring to the >> > upcoming change di

Re: [HACKERS] On partitioning

On Thu, Dec 11, 2014 at 12:00 AM, Amit Kapila wrote: > Yeah either this way or what Josh has suggested upthread, the main > point was that if at all we want to support multi-column list partitioning > then we need to have slightly different syntax, however I feel that we > can leave multi-column l

Re: [HACKERS] Commitfest problems

On Wed, Dec 10, 2014 at 11:00:21PM -0800, Josh Berkus wrote: > On 12/10/2014 10:35 PM, Bruce Momjian wrote: > > I think we are reaching the limits on how much we can do with our > > existing commitfest structure, and it might be time to consider changes. > > While the commitfest process hasn't chan

Re: [HACKERS] [REVIEW] Re: Fix xpath() to return namespace definitions

On 11/5/14 9:50 AM, Ali Akbar wrote: > I noticed somewhat big performance regression if the xml is large (i use > PRODML Product Volume sample from energistics.org ): > * Without patch (tested 3 times): > select unnest(xpath('//a:flow', x, > ARRAY[['a','http://www.prodml.org

Re: [HACKERS] Too strict check when starting from a basebackup taken off a standby

Il 11/12/14 12:38, Andres Freund ha scritto: > On December 11, 2014 9:56:09 AM CET, Heikki Linnakangas > wrote: >> On 12/11/2014 05:45 AM, Andres Freund wrote: >> >> Yeah. I was not able to reproduce this, but I'm clearly missing >> something, since both you and Sergey have seen this happening.

Re: [HACKERS] Review of Refactoring code for sync node detection

On 11/18/2014 11:23 PM, Michael Paquier wrote: On Tue, Nov 18, 2014 at 6:33 PM, Simon Riggs wrote: Can we just wait on this patch until we have the whole feature? Well, this may take some time to even define, and even if goals are clearly defined this may take even more time to have a protot

Re: [HACKERS] Too strict check when starting from a basebackup taken off a standby

On December 11, 2014 9:56:09 AM CET, Heikki Linnakangas wrote: >On 12/11/2014 05:45 AM, Andres Freund wrote: >> A customer recently reported getting "backup_label contains data >> inconsistent with control file" after taking a basebackup from a >standby >> and starting it with a typo in primary_c

Re: [HACKERS] Directory/File Access Permissions for COPY and Generic File Access Functions

I'm marking this as "Rejected" in the commitfest. It's quite clear that this isn't going to fly in its current form. For the COPY FROM use case, I'd suggest just doing COPY FROM STDIN. Yes, it's slower, but not much. And you probably could optimize it further - there's some gratuitous memcpy()

Re: [HACKERS] 9.5: Memory-bounded HashAgg

On Sun, 2014-08-10 at 14:26 -0700, Jeff Davis wrote: > This patch is requires the Memory Accounting patch, or something similar > to track memory usage. > > The attached patch enables hashagg to spill to disk, which means that > hashagg will contain itself to work_mem even if the planner makes a >

Re: [HACKERS] inherit support for foreign tables

(2014/12/11 14:54), Ashutosh Bapat wrote: I marked this as ready for committer. Many thanks! Best regards, Etsuro Fujita -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] [Bug] Inconsistent result for inheritance and FOR UPDATE.

Hello, this is about the second issue. SELECT FROM WHERE FOR UPDATE may return results which does not match the . The following steps will reproduce the problematic behavior (A and B are individual sessions) on master and back to 9.0 but 8.4 gives correct result. I haven't checked on 8.3. - Rep

[HACKERS] [Bug] Duplicate results for inheritance and FOR UPDATE.

Hello, we found (and maybe fixed) two wrong behavior related to inheritance and FOR UPDATE. This report is about one of them. This behavior could be observed on master and back to 8.4 but 8.4 behaves a bit more funny. I haven't checked on 8.3. This issue is that some query returns duplicate rows

Re: [HACKERS] Too strict check when starting from a basebackup taken off a standby

On 12/11/2014 05:45 AM, Andres Freund wrote: A customer recently reported getting "backup_label contains data inconsistent with control file" after taking a basebackup from a standby and starting it with a typo in primary_conninfo. When starting postgres from a basebackup StartupXLOG() has the f

  1   2   >