Re: [HACKERS] Batch update of indexes

On 21 January 2016 at 06:41, konstantin knizhnik wrote: > Certainly for B-Tree we can organize insert buffer (or pending list) as > sorted array or also as a tree. > But in both case complexity of search in this buffer will be O(log(N)), > not O(1). > You are right; search within this buffer is

Re: [HACKERS] Batch update of indexes

On Jan 21, 2016, at 5:14 AM, Simon Riggs wrote: > On 20 January 2016 at 14:55, Konstantin Knizhnik > wrote: > Hi, > > Hi, I glad to see that you interested in that too. > I think this is a good feature and I think it will be very useful to have. > I have already mentioned some related problems

Re: [HACKERS] checkpointer continuous flushing

On Wed, Jan 20, 2016 at 9:07 PM, Andres Freund wrote: > > On 2016-01-20 12:16:24 -0300, Alvaro Herrera wrote: > > Andres Freund wrote: > > > > > The relevant thread is at > > > http://archives.postgresql.org/message-id/CA%2BTgmoaCr3kDPafK5ygYDA9mF9zhObGp_13q0XwkEWsScw6h%3Dw%40mail.gmail.com > > >

Re: [HACKERS] Releasing in September

Michael Paquier writes: > On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote: >> What benefit does porting sqlsmith for inclusion in core have? I can >> only think of costs, including those that you mentioned. > We have automatic buildfarm coverage on many platforms. Perhaps we > could live

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 9:37 PM, Michael Paquier wrote: > We have automatic buildfarm coverage on many platforms. Perhaps we > could live without that with a buildfarm module though. It's not clear that buildfarm coverage makes sense for sqlsmith. If it does make sense, I see no reason why introd

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Thu, Jan 21, 2016 at 2:07 AM, Robert Haas wrote: > > Well, we kind of need to get it right, not just be guessing. > > It looks to me as though GetConnection() only uses the user ID as a > cache lookup key. What it's trying to do is ensure that if user A and > user B need different user mappin

Re: [HACKERS] Releasing in September

On Thu, Jan 21, 2016 at 2:30 PM, Peter Geoghegan wrote: > On Wed, Jan 20, 2016 at 8:23 PM, Michael Paquier > wrote: >> Another tool that we had better IMO put some efforts in porting >> into core is sqlsmith, which would actually be a complete rewrite >> because the upstream code is under GPL lic

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 8:23 PM, Michael Paquier wrote: > Another tool that we had better IMO put some efforts in porting > into core is sqlsmith, which would actually be a complete rewrite > because the upstream code is under GPL license and depends on libpqxx. Then Andreas Seltenreich better ge

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

On Thu, Jan 21, 2016 at 3:07 AM, Alvaro Herrera wrote: > > So far as I can tell, there are three patches in flight here: > Yes, thats right. > * replication slot IO lwlocks > * ability of extensions to request tranches dynamically > * PGPROC > > The first one hasn't been reviewed at all, but the

Re: [HACKERS] Parallel Aggregate

On Thu, Dec 24, 2015 at 5:12 AM, Robert Haas wrote: > On Mon, Dec 21, 2015 at 6:38 PM, David Rowley > wrote: >> On 22 December 2015 at 04:16, Paul Ramsey wrote: >>> >>> Shouldn’t parallel aggregate come into play regardless of scan >>> selectivity? >> >> I'd say that the costing should take into

Re: [HACKERS] [PATCH] better systemd integration

2016-01-21 3:33 GMT+01:00 Peter Eisentraut : > On 1/18/16 10:58 AM, Alvaro Herrera wrote: > > Peter Eisentraut wrote: > >> I have written a couple of patches to improve the integration of the > >> postgres daemon with systemd. > > > > Great. Is anything happening with these patches, or? They've

Re: [HACKERS] Combining Aggregates

On 21 January 2016 at 15:53, Haribabu Kommi wrote: > On Thu, Jan 21, 2016 at 1:33 PM, Haribabu Kommi > wrote: > > > > Here I attached updated patch of parallel aggregate based on the latest > > changes in master. Still it lack of cost comparison of normal aggregate > to > > parallel aggregate be

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 8:32 PM, Michael Paquier wrote: > Perhaps some people are more interested in implementing new > features than working on bugs and would just continue hacking and > arguing about new features, at least a stability period may attract > more committer attention into actual bug

Re: [HACKERS] Releasing in September

On Thu, Jan 21, 2016 at 1:32 PM, Michael Paquier wrote: > On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian wrote: >> On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote: >>> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund wrote: >>> > I think this has very little to do with commitfest sch

Re: [HACKERS] Releasing in September

On Thu, Jan 21, 2016 at 12:59 AM, Bruce Momjian wrote: > On Wed, Jan 20, 2016 at 10:55:07AM -0500, Robert Haas wrote: >> On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund wrote: >> > I think this has very little to do with commitfest schedules, and much >> > more with the "early" forking of the new

Re: [HACKERS] Releasing in September

On Thu, Jan 21, 2016 at 8:51 AM, Peter Geoghegan wrote: > On Wed, Jan 20, 2016 at 2:56 PM, Tom Lane wrote: >> As a concrete example, I recall that Heikki or someone had a tool for >> checking WAL replay by comparing master and slave disk contents. We >> should make an effort to get that into a s

Re: [HACKERS] exposing pg_controldata and pg_config as functions

On Wed, Jan 20, 2016 at 2:32 AM, Joe Conway wrote: > The only things I know of still lacking is: > 1) Documentation > 2) Decision on REVOKE ... FROM PUBLIC Yep, regarding 2) I am the only one actually making noise to protect this information by default, against at least 2 committers :) > I'm ass

Re: [HACKERS] WIP patch to improve amvalidate functions

Alvaro Herrera writes: > Tom Lane wrote: >> I'm posting this now just in case anyone has some comments, or quibbles >> about the overall intent. In particular, if anyone has an idea for a more >> thorough missing-objects check on BRIN opfamilies, I would like to hear >> it. The fact that there a

Re: [HACKERS] ALTER TABLE behind-the-scenes effects' CONTEXT

On 5 January 2016 at 06:45, Simon Riggs wrote: > On 4 January 2016 at 20:44, Alvaro Herrera > wrote: > > >> Maybe >> there are more ALTER TABLE subcommands that should be setting something >> up? In cases where multiple subcommands are being run, it might be >> useful to see which one caused a

Re: [HACKERS] Expanded Objects and Order By

I wrote: > Paul Ramsey writes: >> Thank the Maker, it is reproduceable: returning an expanded header in >> the _in function is not appreciated in a very narrow number of cases. > Thanks for finding a test case! I'll check into it shortly. So the short answer is that the planner assumes, not unr

Re: [HACKERS] Spurious standby query cancellations

On 24 December 2015 at 20:15, Jeff Janes wrote: > On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote: > > On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes > wrote: > >> > >> On further thought, neither do I. The attached patch inverts > >> ResolveRecoveryConflictWithLock to be called back from the

Re: [HACKERS] Combining Aggregates

On Thu, Jan 21, 2016 at 1:33 PM, Haribabu Kommi wrote: > > Here I attached updated patch of parallel aggregate based on the latest > changes in master. Still it lack of cost comparison of normal aggregate to > parallel aggregate because of difficulty. This cost comparison is required > in parallel

Re: [HACKERS] [PATCH] better systemd integration

On 1/18/16 10:58 AM, Alvaro Herrera wrote: > Peter Eisentraut wrote: >> I have written a couple of patches to improve the integration of the >> postgres daemon with systemd. > > Great. Is anything happening with these patches, or? They've been > inactive for quite a while now. Well, they are wa

Re: [HACKERS] Combining Aggregates

On Thu, Jan 21, 2016 at 12:32 PM, David Rowley wrote: > On 21 January 2016 at 04:59, Robert Haas wrote: >> >> On Wed, Jan 20, 2016 at 7:53 AM, David Rowley >> wrote: >> > On 21 January 2016 at 01:44, Robert Haas wrote: >> >> >> >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley >> >> wrote: >> >

Re: [HACKERS] COPY (... tab completion

On 1/19/16 6:00 AM, Andreas Karlsson wrote: > On 01/19/2016 07:55 AM, Michael Paquier wrote: >> +/* If we have COPY BINARY, compelete with list of tables */ >> s/compelete/complete > > Fixed. > >> +else if (TailMatches2("COPY|\\copy", "(")) >> +COMPLETE_WITH_LIST7("SELECT", "TABLE

Re: [HACKERS] WIP patch to improve amvalidate functions

Tom Lane wrote: > I'm posting this now just in case anyone has some comments, or quibbles > about the overall intent. In particular, if anyone has an idea for a more > thorough missing-objects check on BRIN opfamilies, I would like to hear > it. The fact that there are two kinds of opfamilies wi

Re: [HACKERS] Batch update of indexes

On 20 January 2016 at 14:55, Konstantin Knizhnik wrote: > Hi, > > Hi, I glad to see that you interested in that too. >> I think this is a good feature and I think it will be very useful to have. >> I have already mentioned some related problems and possible improvements >> in my presentation. >>

Re: [HACKERS] Combining Aggregates

On 21 January 2016 at 08:06, Robert Haas wrote: > On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > wrote: > > Agreed. So I've attached a version of the patch which does not have any > of > > the serialise/deserialise stuff in it. > > I re-reviewed this and have committed most of it with only mino

Re: [HACKERS] Combining Aggregates

On 21 January 2016 at 04:59, Robert Haas wrote: > On Wed, Jan 20, 2016 at 7:53 AM, David Rowley > wrote: > > On 21 January 2016 at 01:44, Robert Haas wrote: > >> > >> On Wed, Jan 20, 2016 at 7:38 AM, David Rowley > >> wrote: > >> >> To my mind, priority #1 ought to be putting this fine new > >

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

On 21 January 2016 at 06:23, Tomasz Rybak wrote: > > I reviewed more files: Thanks. Can you try to put more whitespace between items? It can be hard to follow at the moment. > pglogical_proto_native.c > > + pq_sendbyte(out, 'N'); /* column name block > follows */ > +

Re: [HACKERS] Expanded Objects and Order By

Paul Ramsey writes: > Thank the Maker, it is reproduceable: returning an expanded header in the _in > function is not appreciated in a very narrow number of cases. Thanks for finding a test case! I'll check into it shortly. regards, tom lane -- Sent via pgsql-hackers

Re: [HACKERS] removal of unused argument in ginInsertCleanup()

On Wed, Jan 20, 2016 at 11:32 PM, Fujii Masao wrote: > I found the unused argument "vac_delay" in ginInsertCleanup(). > I think that we should remove it. Patch attached. Visibly an oversight of dc943ad, +1 for nuking it. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 2:56 PM, Tom Lane wrote: > I think a lesson we *should* have learned by now is that we need to put > more emphasis on testing. That includes not only spending more time on > it, but investing more in testing infrastructure. The buildfarm has been > a huge advance in our a

Re: [HACKERS] Expanded Objects and Order By

Thank the Maker, it is reproduceable: returning an expanded header in the _in function is not appreciated in a very narrow number of cases. Edit arrayfuncs.c:array_in(), change the return line thus: // PG_RETURN_ARRAYTYPE_P(retval); PG_RETURN_DATUM(expand_array(PointerGetDatum(re

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 3:26 PM, Bruce Momjian wrote: > They were both cases where we were surprised and where hasty action did > or could have caused big problems. IMV MulitXacts were not a special case because of how many bugs there were in 9.3.0. Rather, they were a special case because, to th

Re: [HACKERS] Releasing in September

On Thu, Jan 21, 2016 at 12:05:19AM +0100, Andres Freund wrote: > On 2016-01-20 18:02:20 -0500, Bruce Momjian wrote: > > The two sobering blockers I can remember were multi-xact (9.3) and JSONB > > compression (9.4). > > I don't see how those compare. The multixact stuff was all discovered a > fair

Re: [HACKERS] Releasing in September

On 2016-01-20 18:02:20 -0500, Bruce Momjian wrote: > The two sobering blockers I can remember were multi-xact (9.3) and JSONB > compression (9.4). I don't see how those compare. The multixact stuff was all discovered a fair bit after the release, the compression stuff pre release. -- Sent via p

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 05:56:27PM -0500, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Jan 20, 2016 at 01:59:59PM -0800, Peter Geoghegan wrote: > >> I think that we've learned some lessons from the problems with 9.3. I > >> don't think that one of those lessons was "take more time to releas

Re: [HACKERS] Releasing in September

Bruce Momjian writes: > On Wed, Jan 20, 2016 at 01:59:59PM -0800, Peter Geoghegan wrote: >> I think that we've learned some lessons from the problems with 9.3. I >> don't think that one of those lessons was "take more time to release". >

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 06:31:58PM +0100, Joel Jacobson wrote: > On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: > > I think one thing we should work on, is being absolutely religious about > > requiring, say, 2 reviews for every nontrivial contribution. We > > currently seem to have a sign

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 07:48:07PM +, Simon Riggs wrote: > If that is the case, then its too late to change. > > March - last CF > April - integration > May - release Beta > Sept - release Prod > > It seems perfectly OK for me to have Beta start at beginning May and for us to > release in Sep

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 01:59:59PM -0800, Peter Geoghegan wrote: > > My feeble attempts at alleviating this problem a bit are adding more > > testing and removing outdated functionality, but both of those are also > > incredibly abuse-prone activities. > > I think that we've learned some lessons f

[HACKERS] WIP patch to improve amvalidate functions

I spent some time trying to improve the amvalidate functions that were committed in a rather crude state in 65c5fcd353a859da. Attached is a very-much-WIP patch showing where I'm headed: * Check operator and function signatures (argument and result types) not only their strategy numbers. * Apply

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

On Wed, Jan 6, 2016 at 03:18:49PM -0500, Robert Haas wrote: > On Wed, Jan 6, 2016 at 10:43 AM, Catalin Iacob wrote: > > I also think a list of small things suitable for new contributors > > would help attracting them. Not all would stick and go on to larger > > items but hopefully at least some w

Re: [HACKERS] multivariate statistics v8

On 01/20/2016 10:54 PM, Alvaro Herrera wrote: Bruce Momjian wrote: On Wed, Jan 20, 2016 at 02:20:38PM -0500, Robert Haas wrote: On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra wrote: The remaining question is how unique the statistics name should be. My initial plan was to make it uni

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 09:12:07AM -0800, Joshua Drake wrote: > >I just don't buy the Ubuntu release model for our database. Ubuntu is > >trying to balance hot features vs stability, while we are really focused > >on stability, similar to Debian. > > I understand but I think we are missing out on

[HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested I revied more files: pglogical_proto_native.c + pq_sendbyte(o

Re: [HACKERS] More stable query plans via more predictable column statistics

Alvaro Herrera writes: > Tom Lane wrote: >> "Shulgin, Oleksandr" writes: >>> This post summarizes a few weeks of research of ANALYZE statistics >>> distribution on one of our bigger production databases with some real-world >>> data and proposes a patch to rectify some of the oddities observed.

Re: [HACKERS] Minor code improvements to create_foreignscan_plan/ExecInitForeignScan

Etsuro Fujita wrote: > On second thought, I noticed that detecting whether we see a system column > that way needs more cycles in cases where the reltargetlist and the > restriction clauses don't contain any system columns. ISTM that such cases > are rather common, so I'm inclined to keep that co

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 1:37 PM, Peter Eisentraut wrote: > Yeah, a lot of the ideas in this thread, while reasonable, are of the > sort "We need to be better about ..." which sounds a lot like "I need to > be better about exercising". A system based purely on distributed > willpower isn't going t

Re: [HACKERS] multivariate statistics v8

Bruce Momjian wrote: > On Wed, Jan 20, 2016 at 02:20:38PM -0500, Robert Haas wrote: > > On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra > > wrote: > > >The remaining question is how unique the statistics name should be. > > >My initial plan was to make it unique within a table, but that of >

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > On Wed, Jan 20, 2016 at 6:57 PM, Alvaro Herrera > wrote: > > Here's one area where the commitfest app could help the CFM. I would > > like to have a report that shows, for each person, the list of patches > > where they are author, and the list of patches where they are

Re: [HACKERS] More stable query plans via more predictable column statistics

Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > This post summarizes a few weeks of research of ANALYZE statistics > > distribution on one of our bigger production databases with some real-world > > data and proposes a patch to rectify some of the oddities observed. > > Please add this to the

Re: [HACKERS] multivariate statistics v8

On Wed, Jan 20, 2016 at 02:20:38PM -0500, Robert Haas wrote: > On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra > wrote: > >The remaining question is how unique the statistics name should be. > >My initial plan was to make it unique within a table, but that of > >course does not work well

Re: [HACKERS] [PATCH] Refactoring of LWLock tranches

So far as I can tell, there are three patches in flight here: * replication slot IO lwlocks * ability of extensions to request tranches dynamically * PGPROC The first one hasn't been reviewed at all, but the other two have seen a bit of discussion and evolution. Is anyone doing any more reviewin

Re: [HACKERS] Releasing in September

On 1/20/16 1:44 PM, Robert Haas wrote: > And, you know, I did my time fighting major wars to try to compress > the release schedule, and honestly, it wasn't that much fun. The > process we have now is imperfect in many ways, but I no longer have > abuse heaped on me for wanting to boot a patch out

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Mon, Jan 18, 2016 at 6:47 AM, Ashutosh Bapat wrote: > 2. pg_fdw_join_v2.patch: postgres_fdw changes for supporting join pushdown The very first hunk of this patch contains annoying whitespace changes. Even if the result is what pgindent is going to do anyway, such changes should be stripped o

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 6:57 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > > > 4. Submit a patch, review a patch. > > > > Don't review patches? Don't submit patches. > > Here's one area where the commitfest app could help the CFM. I would > like to have a report that shows, for each perso

Re: [HACKERS] Fuzzy substring searching with the pg_trgm extension

Artur Zakirov wrote: > >I don't quite understand why aren't we using a custom GUC variable here. > >These already have SHOW and SET support ... > > > > Added GUC variables: > - pg_trgm.limit > - pg_trgm.substring_limit > I added this variables to the documentation. > show_limit() and set_limit()

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

W dniu 20.01.2016, śro o godzinie 13∶54 +0800, użytkownik Craig Ringer napisał: > On 20 January 2016 at 06:23, Tomasz Rybak > wrote: > > The following review has been posted through the commitfest > > application: > > > Thanks! >   > >   > > + /* Protocol capabilities */ > > + #define PGLOGICAL_P

Re: [HACKERS] Releasing in September

On 20 January 2016 at 20:29, Joshua D. Drake wrote: > On 01/20/2016 10:53 AM, Simon Riggs wrote: > >> On 20 January 2016 at 15:40, Bruce Momjian > > wrote: >> >> Many people where happy with our consistent releasing major releases >> in >> September, e.g. 9.0 to 9

Re: [HACKERS] Why format() adds double quote?

On Wed, Jan 20, 2016 at 4:20 AM, Pavel Stehule wrote: >> If we would go this way, question is if we should back patch this or >> not since the patch apparently changes the existing >> behaviors. Comments? I would think we should not. > > I am sure, so we should not backport this change. This can

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Wed, Jan 20, 2016 at 8:50 AM, Ashutosh Bapat wrote: >> Third, I removed GetUserMappingById(). As mentioned in the email to >> which I replied earlier, that doesn't actually produce the same result >> as the way we're doing it now, and might leave the user ID invalid. > > The comment you quoted

Re: [HACKERS] Releasing in September

On 01/20/2016 10:53 AM, Simon Riggs wrote: On 20 January 2016 at 15:40, Bruce Momjian mailto:br...@momjian.us>> wrote: Many people where happy with our consistent releasing major releases in September, e.g. 9.0 to 9.3: What is the point in having a special mailing list to discuss the r

Re: [HACKERS] postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)

On Wed, Jan 20, 2016 at 8:53 AM, Ashutosh Bapat wrote: > I missed the example plan cache revalidation patch in the previous mail. > Sorry. Here it is. I see. Yeah, I don't see a reason offhand why that wouldn't work. But you need to update src/backend/nodes for the new field in each place where

Re: Odd behavior in foreign table modification (Was: Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW)

On Wed, Jan 20, 2016 at 4:50 AM, Etsuro Fujita wrote: > My concern about that is that would make the code in deparseTargetList() > complicated. > > Essentially, I think your propossal needs a two-pass algorithm for > deparseTargetList; (1) create an integer List of the columns being retrieved > fr

Re: [HACKERS] Releasing in September

On 21/01/16 06:40, Tom Lane wrote: Magnus Hagander writes: That's pretty much what I suggested :) Except that we need to do it for the last one as well. With the only exception that the last one might be a bit longer. But the fact is that the recent of CFs *and* releases, we've taken the approa

Re: [HACKERS] Releasing in September

On 20 January 2016 at 19:45, Robert Haas wrote: > On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane wrote: > > and...@anarazel.de (Andres Freund) writes: > >> On 2016-01-20 18:53:54 +, Simon Riggs wrote: > >>> What is the point in having a special mailing list to discuss the > release > >>> schedule

Re: [HACKERS] Releasing in September

On 20 January 2016 at 15:40, Bruce Momjian wrote: > Many people were happy with our consistent releasing major releases in > September, e.g. 9.0 to 9.3: > > 9.5 2016-01-07 > 9.4 2014-12-18 > 9.3 2013-09-09 <-- > 9.2 2012-09-10 <-- > 9.1 2011-09-12

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane wrote: > and...@anarazel.de (Andres Freund) writes: >> On 2016-01-20 18:53:54 +, Simon Riggs wrote: >>> What is the point in having a special mailing list to discuss the release >>> schedule plus a face-to-face dev meeting to discuss this if we are goi

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 11:13 AM, Andres Freund wrote: > That list exists to discuss concrete releases, and is separate so we > e.g. can mention there's security issues and such. This topic in > contrast quite validly merits input from more then the usual suspects > going to a developer meeting.

Re: [HACKERS] Releasing in September

and...@anarazel.de (Andres Freund) writes: > On 2016-01-20 18:53:54 +, Simon Riggs wrote: >> What is the point in having a special mailing list to discuss the release >> schedule plus a face-to-face dev meeting to discuss this if we are going to >> discuss it here? > That list exists to discus

Re: [HACKERS] multivariate statistics v8

On Wed, Dec 23, 2015 at 2:07 PM, Tomas Vondra wrote: >The remaining question is how unique the statistics name should be. >My initial plan was to make it unique within a table, but that of >course does not work well with the DROP STATISTICS (it'd have to >specify the table name als

Re: [HACKERS] Releasing in September

On 2016-01-20 18:53:54 +, Simon Riggs wrote: > What is the point in having a special mailing list to discuss the release > schedule plus a face-to-face dev meeting to discuss this if we are going to > discuss it here? That list exists to discuss concrete releases, and is separate so we e.g. ca

Re: [HACKERS] Releasing in September

On 20 January 2016 at 17:03, Tom Lane wrote: > Robert Haas writes: > > But I'm not very sure that we're talking about the same set of people > > here. If we're going to go to a system where nobody's allowed to > > commit anything for the next release until the current release is > > finalized,

Re: [HACKERS] Combining Aggregates

On Wed, Jan 20, 2016 at 7:38 AM, David Rowley wrote: > Agreed. So I've attached a version of the patch which does not have any of > the serialise/deserialise stuff in it. I re-reviewed this and have committed most of it with only minor kibitizing. A few notes: - I changed the EXPLAIN code, sinc

Re: [HACKERS] Releasing in September

On 20 January 2016 at 16:29, Andres Freund wrote: > I think one thing we should work on, is being absolutely religious about > requiring, say, 2 reviews for every nontrivial contribution. We > currently seem to have a significantly increased submission rate, and at > the same time the number of

Re: [HACKERS] Releasing in September

On 20 January 2016 at 15:55, Robert Haas wrote: > On Wed, Jan 20, 2016 at 10:48 AM, Andres Freund > wrote: > > On 2016-01-20 10:40:14 -0500, Bruce Momjian wrote: > >> We have gotten off of that cycle in the last two major releases, and > >> this isn't going to improve as long as we have commitfe

Re: [HACKERS] Releasing in September

On 20 January 2016 at 15:40, Bruce Momjian wrote: > Many people where happy with our consistent releasing major releases in > September, e.g. 9.0 to 9.3: > What is the point in having a special mailing list to discuss the release schedule plus a face-to-face dev meeting to discuss this if we are

Re: [HACKERS] custom function for converting human readable sizes to bytes

2016-01-19 4:45 GMT+01:00 Vitaly Burovoy : > On 1/4/16, Pavel Stehule wrote: > > 2016-01-04 18:13 GMT+01:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> : > >> On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule > wrote: > >> > 2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr < > oleksandr.shul..

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 1:29 PM, Andres Freund wrote: > On 2016-01-20 13:13:29 -0500, Robert Haas wrote: >> (3) Andres's multixact reworks landed quite late and IMHO were not >> safe enough to back-patch, yet they needed to be in the release. In >> my view, the last major fix for > > At least in

Re: [HACKERS] Releasing in September

On 2016-01-20 13:13:29 -0500, Robert Haas wrote: > (3) Andres's multixact reworks landed quite late and IMHO were not > safe enough to back-patch, yet they needed to be in the release. In > my view, the last major fix for At least in that case I was, for a long while, basically hoping for more in

Re: [HACKERS] Releasing in September

On 2016-01-20 13:03:05 -0500, Tom Lane wrote: > I am not sure what exactly ought to be different about them [small > patches], but probably something should. I think for small patches, > we are using the CF app mostly to be sure things don't fall through > the cracks, but maybe we don't need the w

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 12:03 PM, Tom Lane wrote: > Robert Haas writes: >> But I'm not very sure that we're talking about the same set of people >> here. If we're going to go to a system where nobody's allowed to >> commit anything for the next release until the current release is >> finalized,

Re: [HACKERS] Releasing in September

Andres Freund writes: > On 2016-01-20 09:48:24 -0800, David E. Wheeler wrote: >> There will always be patches desirable-enough that they will be reviewed >> whether or not the submitter reviewed other patches. > I think that's actually getting less and less true. By now the really > desirable-en

Re: [HACKERS] Releasing in September

On 2016-01-20 19:00:05 +0100, Magnus Hagander wrote: > And you want the actual patches, and not just a count? I think the actual patches makes sense, because reviewing one 200KB patch obviously is something different than reviewing 3 onelinesrs. -- Sent via pgsql-hackers mailing list (pgsql-hac

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > On Jan 20, 2016 18:57, "Alvaro Herrera" wrote: > > Here's one area where the commitfest app could help the CFM. I would > > like to have a report that shows, for each person, the list of patches > > where they are author, and the list of patches where they are reviewer.

Re: [HACKERS] Releasing in September

On Jan 20, 2016 18:57, "Alvaro Herrera" wrote: > > Joshua D. Drake wrote: > > > 4. Submit a patch, review a patch. > > > > Don't review patches? Don't submit patches. > > Here's one area where the commitfest app could help the CFM. I would > like to have a report that shows, for each person, the

Re: [HACKERS] Releasing in September

Joshua D. Drake wrote: > 4. Submit a patch, review a patch. > > Don't review patches? Don't submit patches. Here's one area where the commitfest app could help the CFM. I would like to have a report that shows, for each person, the list of patches where they are author, and the list of patches

Re: [HACKERS] Releasing in September

On 01/20/2016 09:48 AM, David E. Wheeler wrote: On Jan 20, 2016, at 9:42 AM, Joshua D. Drake wrote: 4. Submit a patch, review a patch. Don't review patches? Don't submit patches. There will always be patches desirable-enough that they will be reviewed whether or not the submitter reviewed

Re: [HACKERS] Releasing in September

On 2016-01-20 09:48:24 -0800, David E. Wheeler wrote: > There will always be patches desirable-enough that they will be reviewed > whether or not the submitter reviewed other patches. I think that's actually getting less and less true. By now the really desirable-enough features imply so much wor

Re: [HACKERS] Releasing in September

Magnus Hagander wrote: > Except that we need to do it for the last one as well. With the only > exception that the last one might be a bit longer. But the fact is that the > recent of CFs *and* releases, we've taken the approach of closing the CF > when everything in it is done or explicitly revie

Re: [HACKERS] jsonb array-style subscription

On 20 January 2016 at 02:14, Alvaro Herrera wrote: > Dmitry Dolgov wrote: > > > I've cleaned up the code, created a separate JsonbRef node (and there > are a > > lot of small changes because of that), abandoned an idea of "deep > nesting" > > of assignments (because it doesn't relate to jsonb sub

Re: [HACKERS] PostgreSQL 9.5.0 regress tests fails with Python 3.5.0

Pavel Stehule writes: > make check-world fails, > It is fixed in HEAD. BTW, I have now spun up a new buildfarm member "longfin", which is testing against Python 3.5.1 (except in the 9.1 branch, where that doesn't work). regards, tom lane -- Sent via pgsql-hackers maili

Re: [HACKERS] Releasing in September

On Jan 20, 2016, at 9:42 AM, Joshua D. Drake wrote: > 4. Submit a patch, review a patch. > > Don't review patches? Don't submit patches. There will always be patches desirable-enough that they will be reviewed whether or not the submitter reviewed other patches. And there will often be patche

Re: [HACKERS] Releasing in September

On 2016-01-20 09:42:28 -0800, Joshua D. Drake wrote: > Don't review patches? Don't submit patches. Absolutely. While I think encouraging reviewers is a good thing, it seems independent of requiring contributors to do quid-pro-quo reviews. There'll always be people too busy or uninterested in revie

Re: [HACKERS] Releasing in September

On 01/20/2016 09:31 AM, Joel Jacobson wrote: On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: I think one thing we should work on, is being absolutely religious about requiring, say, 2 reviews for every nontrivial contribution. We currently seem to have a significantly increased submissio

Re: [HACKERS] Releasing in September

Magnus Hagander writes: > That's pretty much what I suggested :) > Except that we need to do it for the last one as well. With the only > exception that the last one might be a bit longer. But the fact is that the > recent of CFs *and* releases, we've taken the approach of closing the CF > when e

Re: [HACKERS] Releasing in September

On Wed, Jan 20, 2016 at 5:29 PM, Andres Freund wrote: > I think one thing we should work on, is being absolutely religious about > requiring, say, 2 reviews for every nontrivial contribution. We > currently seem to have a significantly increased submission rate, and at > the same time the number

Re: [HACKERS] Proposal for UPDATE: do not insert new tuple on heap if update does not change data

On Wed, Jan 20, 2016 at 3:55 AM, Gasper Zejn wrote: > I was wondering if PostgreSQL adds new tuple if data is not changed > when using UPDATE. It turns out it does add them and I think it might > be beneficial not to add a new tuple in this case, since it causes a > great deal of maintenance: upd

  1   2   >