Re: [HACKERS] checkpointer continuous flushing - V18

On Thu, Mar 10, 2016 at 11:18 PM, Fabien COELHO wrote: > I can only concur! > > The "Performance Tips" chapter (II.14) is more user/query oriented. The > "Server Administration" bool (III) does not discuss this much. That's definitely one area in which the docs are lacking

Re: [HACKERS] checkpointer continuous flushing

I just pushed the two major remaining patches in this thread. Hurray! Nine months the this baby out:-) -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] checkpointer continuous flushing - V18

As you wish. I thought that understanding the underlying performance model with sequential writes written in chunks is important for the admin, and as this guc would have an impact on performance it should be hinted about, including the limits of its effect where large bases will converge to

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Fri, Mar 11, 2016 at 12:28 AM, Robert Haas wrote: > > > Committed with some further editing. In particular, the way you > determined whether we could safely access the tranche information for > any given ID was wrong; please check over what I did and make sure > that

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Fri, Mar 11, 2016 at 6:31 PM, Thomas Munro wrote: > I'm not sure what to make of the pre-existing comment about following > HOT-chains and concurrent index builds (which I moved). Does it mean > there is some way that CREATE INDEX CONCURRENTLY could cause us to

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/11 13:16, Robert Haas wrote: > On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote > wrote: >> So, from what I understand here, we should not put total count of index >> pages into st_progress_param; rather, have the client (reading >> pg_stat_progress_vacuum)

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Fri, Mar 11, 2016 at 10:00 AM, Simon Riggs wrote: > On 10 March 2016 at 20:36, Thomas Munro > wrote: >> >> On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs >> wrote: >> > On 3 February 2016 at 23:12, Thomas Munro >> >

Re: [HACKERS] Proposal: RETURNING primary_key()

On 03/10/2016 08:28 PM, Craig Ringer wrote: On 11 March 2016 at 03:07, Igal @ Lucee.org > wrote: I noticed that you usually don't put html in the emails here, but I think that it's appropriate here to show the information in a clear way (also,

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > On 2016-03-10 15:03:41 -0500, Tom Lane wrote: >> What it encourages is having module boundaries that actually mean >> something, as well as code that can be refactored without having >> to worry about which extensions will complain about it. > I

Re: [HACKERS] Proposal: RETURNING primary_key()

On 11 March 2016 at 03:07, Igal @ Lucee.org wrote: > > I noticed that you usually don't put html in the emails here, but I think > that it's appropriate here to show the information in a clear way (also, > according to my computer it's 2016). > Pretty sure we have at least one

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

> > Yes, I think we use this rubric quite often, and I agree it's a good one. > > > Trying to e.g. select a different number of columns into a different > > number of variables in a PL/pgSQL function doesn't throw an error. > > Bad. :( > > Yeah, I'm sympathetic to that request. That seems like

Re: [HACKERS] WIP: Upper planner pathification

Hi, On 2016-03-10 15:03:41 -0500, Tom Lane wrote: > Andres Freund writes: > > Primarily because create_plan(), and/or its children, have to know about > > what you're doing; you can hide some, but not all, things below > > CustomScan nodes. > > And which of those things does

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Mar 10, 2016 at 7:22 PM, Peter Eisentraut wrote: > Arguably, if everyone followed "my" approach, this should be very easy > to fix everywhere. I don't think that there is any clear indication that the OpenSSL people would share that view. Or my view. Or anything that's

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-11 0:17 GMT+01:00 Tom Lane : > Robert Haas writes: > > Or ... maybe this is intentional behavior? Now that I think about it, > > doesn't each backend cache this info the first time its transaction > > reads the data? > > Your view of

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 10, 2016 at 9:04 PM, Amit Langote wrote: > So, from what I understand here, we should not put total count of index > pages into st_progress_param; rather, have the client (reading > pg_stat_progress_vacuum) derive it using pg_indexes_size() (?), as and >

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 10:49 PM, Joel Jacobson wrote: > On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: >> Well, this was discussed. If we keep the Boolean "waiting" column, then >> either: > > Oh, sorry for missing out on that discussion. > >> 1.

Re: [HACKERS] Move PinBuffer and UnpinBuffer to atomics

On Thu, Mar 10, 2016 at 8:26 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > I don't think we can rely on median that much if we have only 3 runs. > For 3 runs we can only apply Kornfeld method which claims that confidence > interval should be between lower and upper values. > Since

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 9:19 AM, Joel Jacobson wrote: > > On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: > > Well, this was discussed. If we keep the Boolean "waiting" column, then either: > > Oh, sorry for missing out on that discussion. > > > 1.

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-03-11 04:50:45 +0100, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 11:40 PM, Robert Haas wrote: > > We need to decide what to do about this. I disagree with Peter: I > > think that regardless of stdbool, what we've got right now is sloppy > > coding - bad style

Re: [HACKERS] GinPageIs* don't actually return a boolean

On 2016-03-02 21:48:16 -0500, Peter Eisentraut wrote: > After reviewing this thread and relevant internet lore, I think this > might be the wrong way to address this problem. It is in general not > guaranteed in C that a Boolean-sounding function or macro returns 0 or > 1. Prime examples are

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Thu, Mar 10, 2016 at 11:40 PM, Robert Haas wrote: > We need to decide what to do about this. I disagree with Peter: I > think that regardless of stdbool, what we've got right now is sloppy > coding - bad style if nothing else. Furthermore, I think that while C > lets

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Fri, Mar 11, 2016 at 9:36 AM, Robert Haas wrote: > Well, this was discussed. If we keep the Boolean "waiting" column, then > either: Oh, sorry for missing out on that discussion. > 1. We make it true only for heavyweight lock waits, and false for > other kinds of

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Mar 11, 2016 at 6:16 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 1:41 PM, Masahiko Sawada > wrote: >> On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas wrote: >>> This 001 patch looks so little like what I was

Re: [HACKERS] Proposal: RETURNING primary_key()

On Mar 10, 2016, at 2:07 PM, Igal @ Lucee.org wrote: > (Side note: This was my first, and hopefully my last, experience with Oracle > database, and it's been a real PITA. If I had tried it out some 20 years ago > then the experience would have probably led me to sell the

Re: [HACKERS] Fix for OpenSSL error queue bug

On 3/10/16 9:38 PM, Peter Geoghegan wrote: > Looked at your proposed patch. Will respond to your original mail on the > matter. > > On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote: >> I think clearing the error after a call is not necessary. The API >> clearly requires

Re: [HACKERS] Adjusting the API of pull_var_clause()

Now, I'm pretty sure that the last time we touched pull_var_clause's > API, we intentionally set it up to force every call site to be visited > when new behaviors were added. But right at the moment that's looking > like it was a bad call. > > An alternative API design could look like > > #define

Re: [HACKERS] Using quicksort for every external sort run

On Sun, Feb 14, 2016 at 8:01 PM, Peter Geoghegan wrote: > The query I'm testing is: "reindex index pgbench_accounts_pkey;" > > Now, with a maintenance_work_mem of 5MB, the most recent revision of > my patch takes about 54.2 seconds to complete this, as compared to > master's 44.4

Re: [HACKERS] Fix for OpenSSL error queue bug

Looked at your proposed patch. Will respond to your original mail on the matter. On Thu, Mar 3, 2016 at 4:15 PM, Peter Eisentraut wrote: > I think clearing the error after a call is not necessary. The API > clearly requires that you should clear the error queue before a call,

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 8:31 PM, Joel Jacobson wrote: > This is an excellent feature, thanks! > But can we please keep the old boolean waiting column? > I see no reason to break backward-compatibility. Or maybe I'm missing > something. Well, this was discussed. If we keep the

Re: [HACKERS] Relaxing SSL key permission checks

On 3/4/16 3:55 PM, Alvaro Herrera wrote: > * it failed to check for S_IXUSR, so permissions 0700 were okay, in > contradiction with what the error message indicates. This is a > preexisting bug actually. Do we want to fix it by preventing a > user-executable file (possibly breaking compability

Re: [HACKERS] Fix for OpenSSL error queue bug

On 3/10/16 6:10 PM, Peter Geoghegan wrote: > On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote: >> Getting to it very soon. Just really busy right this moment. > > That said, I agree with Peter's remarks about doing this frontend and > backend. So, while I'm not sure, I

Re: [HACKERS] [PROPOSAL] VACUUM Progress Checker.

On 2016/03/10 23:29, Robert Haas wrote: > On Thu, Mar 10, 2016 at 3:08 AM, Amit Langote > wrote: >> Hi Vinayak, >> >> Thanks for the quick review! > > Committed 0001 earlier this morning. Thanks! > On 0002: > > + /* total_index_blks */ > +

Re: [HACKERS] Relation extension scalability

On 11/03/16 02:44, Dilip Kumar wrote: On Fri, Mar 11, 2016 at 12:04 AM, Petr Jelinek > wrote: Thanks for looking.. Those look good. The patch looks good in general now. I am bit scared by the lockWaiters * 20 as it can result in

Re: [HACKERS] Optimizer questions

I wrote: > As far as that goes, it seems to me after thinking about it that > non-sort-column tlist items containing SRFs should always be postponed, > too. Performing a SRF before sorting bloats the sort data vertically, > rather than horizontally, but it's still bloat. (Although as against >

Re: [HACKERS] Relation extension scalability

On Fri, Mar 11, 2016 at 12:04 AM, Petr Jelinek wrote: Thanks for looking.. Those look good. The patch looks good in general now. I am bit scared by > the lockWaiters * 20 as it can result in relatively big changes in rare > corner cases when for example a lot of backends

Re: [HACKERS] checkpointer continuous flushing

Hi, I just pushed the two major remaining patches in this thread. Let's see what the buildfarm has to say; I'd not be surprised if there's some lingering portability problem in the flushing code. There's one remaining issue we definitely want to resolve before the next release: Right now we

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

This is an excellent feature, thanks! But can we please keep the old boolean waiting column? I see no reason to break backward-compatibility. Or maybe I'm missing something. I just had to commit this to make our system run locally on 9.6: commit 2e189f85fa56724bec5c5cab2fcf0d2f3a4ce22a Author:

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-03-11 00:23:56 +0100, Fabien COELHO wrote: > As you wish. I thought that understanding the underlying performance model > with sequential writes written in chunks is important for the admin, and as > this guc would have an impact on performance it should be hinted about, > including the

Re: [HACKERS] checkpointer continuous flushing - V18

[...] If the default is in pages, maybe you could state it and afterwards translate it in size. Hm, I think that's more complicated for users than it's worth. As you wish. I liked the number of pages you used initially because it really gives a hint of how much random IOs are avoided when

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

Robert Haas writes: > Or ... maybe this is intentional behavior? Now that I think about it, > doesn't each backend cache this info the first time its transaction > reads the data? Your view of pg_stat_activity is supposed to hold still within a transaction, yes.

Re: [HACKERS] checkpointer continuous flushing - V18

Hello Andres, I'm not sure I've seen these performance... If you have hard evidence, please feel free to share it. Man, are you intentionally trying to be hard to work with? Sorry, I do not understand this remark. You were refering to some latency measures in your answer, and I was just

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Mar 10, 2016 at 3:09 PM, Peter Geoghegan wrote: > Getting to it very soon. Just really busy right this moment. That said, I agree with Peter's remarks about doing this frontend and backend. So, while I'm not sure, I think we're in agreement on all issues. I would have no

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Mar 10, 2016 at 2:50 PM, Robert Haas wrote: > So what's the next step here? Peter G, are you planning to update the > patch based on this review from Peter E? If not, Peter E, do you want > to update the patch and commit? If neither, I'm going to mark this >

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-03-10 23:43:46 +0100, Fabien COELHO wrote: > > > > >Whenever more than bgwriter_flush_after bytes have > >been written by the bgwriter, attempt to force the OS to issue these > >writes to the underlying storage. Doing so will limit the amount of > >

Re: [HACKERS] Fix for OpenSSL error queue bug

On Thu, Mar 3, 2016 at 7:15 PM, Peter Eisentraut wrote: > On 2/5/16 5:04 AM, Peter Geoghegan wrote: >> As Heikki goes into on that thread, the appropriate action seems to be >> to constantly reset the error queue, and to make sure that we >> ourselves clear the queue

Re: [HACKERS] checkpointer continuous flushing - V18

Whenever more than bgwriter_flush_after bytes have been written by the bgwriter, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-03-10 23:38:38 +0100, Fabien COELHO wrote: > I'm not sure I've seen these performance... If you have hard evidence, > please feel free to share it. Man, are you intentionally trying to be hard to work with? To quote the email you responded to: > My current plan is to commit this with

Re: [HACKERS] GinPageIs* don't actually return a boolean

On Wed, Mar 2, 2016 at 9:48 PM, Peter Eisentraut wrote: > On 2/11/16 9:30 PM, Michael Paquier wrote: >>> Well, Yury was saying upthread that some MSVC versions have a problem >>> with the existing coding, which would be a reason to back-patch ... >>> but I'd like to see a failing

Re: [HACKERS] checkpointer continuous flushing - V18

[...] I had originally kept it with one context per tablespace after refactoring this, but found that it gave worse results in rate limited loads even over only two tablespaces. That's on SSDs though. Might just mean that a smaller context size is better on SSD, and it could still be

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-03-10 17:33:33 -0500, Robert Haas wrote: > On Thu, Mar 10, 2016 at 5:24 PM, Andres Freund wrote: > > On 2016-02-21 09:49:53 +0530, Robert Haas wrote: > >> I think there might be a semantic distinction between these two terms. > >> Doesn't writeback mean writing pages

Re: [HACKERS] checkpointer continuous flushing - V18

On Thu, Mar 10, 2016 at 5:24 PM, Andres Freund wrote: > On 2016-02-21 09:49:53 +0530, Robert Haas wrote: >> I think there might be a semantic distinction between these two terms. >> Doesn't writeback mean writing pages to disk, and flushing mean making >> sure that they are

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-02-21 09:49:53 +0530, Robert Haas wrote: > I think there might be a semantic distinction between these two terms. > Doesn't writeback mean writing pages to disk, and flushing mean making > sure that they are durably on disk? So for example when the Linux > kernel thinks there is too much

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 5:07 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote: >> On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule >> wrote: >>> Maybe it be clear from attached text file >> >> Uh,

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 5:05 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule > wrote: >> Maybe it be clear from attached text file > > Uh, yikes, that looks messed up, but I wouldn't have thought this > commit would have

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 4:51 PM, Pavel Stehule wrote: > Maybe it be clear from attached text file Uh, yikes, that looks messed up, but I wouldn't have thought this commit would have changed anything there one way or the other. The current query is reported by

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

2016-03-10 22:24 GMT+01:00 Robert Haas : > > rhaas=# select query, state, wait_event, wait_event_type from > pg_stat_activity; > query > | state | wait_event | wait_event_type > >

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining? - and backup / restore issue

> Hmm. The meaning of funcs.inline depends on the search_path, not just during > dump restoration but all the time. So anything uses it under a different > search_path setting than the normal one will have this kind of problem; not > just > dump/restore. > I don't have a very good idea

Re: [HACKERS] checkpointer continuous flushing - V18

On 2016-03-08 09:28:15 +0100, Fabien COELHO wrote: > > >>>Now I cannot see how having one context per table space would have a > >>>significant negative performance impact. > >> > >>The 'dirty data' etc. limits are global, not per block device. By having > >>several contexts with unflushed dirty

Re: [HACKERS] [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

On Thu, Mar 10, 2016 at 3:44 PM, Pavel Stehule wrote: > I am trying to test this feature, and there I see not actual data. Maybe > this behave is not related to this patch: > > create table foo(a int); > insert into foo values(10); > > session one: > > begin; select *

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Mar 10, 2016 at 1:41 PM, Masahiko Sawada wrote: > On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas wrote: >> This 001 patch looks so little like what I was expecting that I >> decided to start over from scratch. The new version I wrote is >>

Re: [HACKERS] auto_explain sample rate

On 10/03/16 20:59, Julien Rouhaud wrote: On 10/03/2016 04:37, Petr Jelinek wrote: On 17/02/16 01:17, Julien Rouhaud wrote: Agreed, it's too obscure. Attached v4 fixes as you said. Seems to be simple enough patch and works. However I would like documentation to say that the range is 0 to 1

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On 10 March 2016 at 20:36, Thomas Munro wrote: > On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs > wrote: > > On 3 February 2016 at 23:12, Thomas Munro > > > wrote: > > > >> > >> It quacks suspiciously like a

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 11/03/16 08:48, Igal @ Lucee.org wrote: On 3/10/2016 11:44 AM, Robert Haas wrote: On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs wrote: But I still don't know "meh" means. Maybe this helps? https://en.wikipedia.org/wiki/Meh LOL https://en.wikipedia.org/wiki/LOL

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs wrote: > On 3 February 2016 at 23:12, Thomas Munro > wrote: > >> >> It quacks suspiciously like a bug. > > > Agreed > > What's more important is that is very publicly a bug in the eyes of others >

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 11:45 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston > wrote: > > I tend to think we err toward this too much. This seems like development > > concerns trumping usability. Consider that

Re: [HACKERS] Patch to implement pg_current_logfile() function

Gilles Darold writes: > Then, should I have to use an alternate file to store the information or > implement a bidirectional communication with the syslogger? I'd just define a new single-purpose file $PGDATA/log_file_name or some such. regards,

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > On 2016-03-10 14:16:03 -0500, Tom Lane wrote: >> I don't deny that you *could* continue to do things that way, but >> I dispute that it's a good idea. Why can't you generate a Path tree >> and then ask create_plan() to convert it? > Primarily because

Re: [HACKERS] WIP: Upper planner pathification

On Thu, Mar 10, 2016 at 8:45 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 2:41 PM, Andres Freund wrote: > > ISTM, that there's good enough reasons to go either way; I don't see > > what we're gaining by making these private. That just encourages >

Re: [HACKERS] auto_explain sample rate

On 10/03/2016 04:37, Petr Jelinek wrote: > On 17/02/16 01:17, Julien Rouhaud wrote: >> >> Agreed, it's too obscure. Attached v4 fixes as you said. >> > > Seems to be simple enough patch and works. However I would like > documentation to say that the range is 0 to 1 and represents fraction of >

Re: [HACKERS] WIP: Upper planner pathification

On Thu, Mar 10, 2016 at 11:45 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 2:41 PM, Andres Freund wrote: >> ISTM, that there's good enough reasons to go either way; I don't see >> what we're gaining by making these private. That just encourages >>

Re: [HACKERS] WIP: Detecting SSI conflicts before reporting constraint violations

On 3 February 2016 at 23:12, Thomas Munro wrote: > It quacks suspiciously like a bug. > Agreed What's more important is that is very publicly a bug in the eyes of others and should be fixed and backpatched soon. We have a maintenance release coming in a couple

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 3/10/2016 11:44 AM, Robert Haas wrote: On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs wrote: But I still don't know "meh" means. Maybe this helps? https://en.wikipedia.org/wiki/Meh LOL https://en.wikipedia.org/wiki/LOL -- Sent via pgsql-hackers mailing list

Re: [HACKERS] proposal: function parse_ident

2016-03-10 15:34 GMT+01:00 Teodor Sigaev : > select >> >> parse_ident(E'X\rXX'); >> >> >> I am sending updated patch - I used json function for correct escaping - >> the >> escaping behave is same. >> > > Hmm, it doesn't

Re: [HACKERS] Patch to implement pg_current_logfile() function

Le 10/03/2016 16:26, Tom Lane a écrit : > Robert Haas writes: >> On Wed, Mar 9, 2016 at 12:32 PM, Gilles Darold >> wrote: >>> I choose to allow the log collector to write his current log file name >>> into the lock file 'postmaster.pid'. >> Gosh,

Re: [HACKERS] WIP: Upper planner pathification

On Thu, Mar 10, 2016 at 2:41 PM, Andres Freund wrote: > ISTM, that there's good enough reasons to go either way; I don't see > what we're gaining by making these private. That just encourages > copy-paste coding. +1. Frustrating Citus's attempt to open-source their stuff is

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 2:35 PM, Simon Riggs wrote: > But I still don't know "meh" means. Maybe this helps? https://en.wikipedia.org/wiki/Meh -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] WIP: Upper planner pathification

On 2016-03-10 14:16:03 -0500, Tom Lane wrote: > Andres Freund writes: > > In Citus' case a full PlannedStmt is generated on the master node, to > > combine the data generated on worker nodes (where the bog standard > > postgres planner is used). It's not the only way to do

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

On 2016-03-10 20:31:55 +0100, Michael Paquier wrote: > On Thu, Mar 10, 2016 at 7:52 PM, Andres Freund wrote: > > Having to backpatch a single system() invocation + find_other_exec() > > call, and backporting a more general FRONTEND version of initdb's > > fsync_pgdata() are

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On 10 March 2016 at 18:45, Robert Haas wrote: > On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston > wrote: > > I tend to think we err toward this too much. This seems like development > > concerns trumping usability. Consider that anything

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 10:39 AM, Greg Stark wrote: > I want to rerun these on a dedicated machine and with trace_sort > enabled so that we can see how many merge passes were actually > happening and how much I/O was actually happening. Putting the results in context, by keeping

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

On Thu, Mar 10, 2016 at 7:52 PM, Andres Freund wrote: >> a target data folder should be stopped properly to be able to rewind, >> and it is better to avoid dependencies between utilities if that's not >> strictly necessary. initdb is likely to be installed side-by-side >>

Re: [HACKERS] Freeze avoidance of very large table.

On Thu, Mar 10, 2016 at 1:41 PM, Masahiko Sawada wrote: > On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas wrote: >> This 001 patch looks so little like what I was expecting that I >> decided to start over from scratch. The new version I wrote is >>

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > On 2016-03-10 13:48:31 -0500, Tom Lane wrote: >> That was intentional: in my opinion, nothing outside createplan.c ought >> to be making Plan nodes anymore. The expectation is that you make a >> Path describing what you want. Can you explain why, in

Re: [HACKERS] Proposal: RETURNING primary_key()

On 3/8/2016 4:42 PM, Craig Ringer wrote: On 9 March 2016 at 05:40, Igal @ Lucee.org > wrote: I will try to gather more information about the other DBMSs and drivers and will post my findings here when I have them. Thanks. I know that's not the

Re: [HACKERS] WIP: Upper planner pathification

On 2016-03-10 13:48:31 -0500, Tom Lane wrote: > Andres Freund writes: > > I see that you made a lot of formerly externally visible make_* routines > > static. The Citus extension (which will be open source in a few days) > > uses several of these (make_agg,

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

On Thu, Mar 10, 2016 at 12:18 AM, Amit Kapila wrote: > On Wed, Mar 9, 2016 at 7:17 PM, Robert Haas wrote: >> >> On Wed, Mar 9, 2016 at 8:31 AM, Amit Kapila >> wrote: >> > Thanks for the suggestion. I have updated the

Re: [HACKERS] pg_rewind just doesn't fsync *anything*?

Hi, On 2016-03-10 08:47:16 +0100, Michael Paquier wrote: > Still, I think that we had better fsync only entries that are modified > by pg_rewind, and files that got updated, and not the whole directory Why? If any files in there are dirty, they need to be fsynced. If they're not dirty, fsync's

Re: [HACKERS] WIP: Upper planner pathification

Andres Freund writes: > I see that you made a lot of formerly externally visible make_* routines > static. The Citus extension (which will be open source in a few days) > uses several of these (make_agg, make_sort_from_sortclauses, make_limit > at least). > Can we please

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 11:33 AM, David G. Johnston wrote: > I tend to think we err toward this too much. This seems like development > concerns trumping usability. Consider that anything someone took the time > to write and polish to make committable to core was

Re: [HACKERS] Freeze avoidance of very large table.

On Fri, Mar 11, 2016 at 1:03 AM, Robert Haas wrote: > This 001 patch looks so little like what I was expecting that I > decided to start over from scratch. The new version I wrote is > attached here. I don't understand why your version tinkers with the > logic for setting

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 1:40 PM, Tomas Vondra wrote: > I was thinking about running some benchmarks on this patch, but the > thread is pretty huge so I want to make sure I'm not missing something > and this is indeed the most recent version. I also ran some

Re: [HACKERS] Using quicksort for every external sort run

On Thu, Mar 10, 2016 at 5:40 AM, Tomas Vondra wrote: > I was thinking about running some benchmarks on this patch, but the > thread is pretty huge so I want to make sure I'm not missing something > and this is indeed the most recent version. Wait 24 - 48 hours,

Re: [HACKERS] Relation extension scalability

On 10/03/16 09:57, Dilip Kumar wrote: On Thu, Mar 10, 2016 at 7:55 AM, Petr Jelinek > wrote: Thanks for the comments.. Hmm, why did you remove the comment above the call to UnlockRelationForExtension? While re factoring I lose this

Re: [HACKERS] WIP: Upper planner pathification

Hi Tom, On 2016-02-28 15:03:28 -0500, Tom Lane wrote: > diff --git a/src/include/optimizer/planmain.h > b/src/include/optimizer/planmain.h > index eaa642b..cd7338a 100644 > *** a/src/include/optimizer/planmain.h > --- b/src/include/optimizer/planmain.h > *** extern RelOptInfo

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

removed leftover development comment On Thu, Mar 10, 2016 at 11:02 AM, Corey Huinker wrote: > On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas > wrote: > >> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs >> wrote: >> > On 10

[HACKERS] Adjusting the API of pull_var_clause()

Over in the "Optimizer questions" thread, it's become apparent that we need to fix pull_var_clause() to offer multiple behaviors for WindowFunc nodes that are parallel to the ones it has for Aggrefs (viz, reject, recurse, or include in result). This should've been done when window functions were

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Tom Lane wrote: > Alexey Grishchenko > writes: > > No, my fix handles this well. > > In fact, with the first function call you allocate global variables > > representing Python function input parameters, call the function and > > receive

Re: [HACKERS] WAL log only necessary part of 2PC GID

On 10/03/16 13:43, Pavan Deolasee wrote: On Wed, Mar 9, 2016 at 7:56 PM, Petr Jelinek > wrote: Hi, I wonder why you define the gidlen as uint32 when it would fit into uint8 which in the current TwoPhaseFileHeader struct should be

Re: [HACKERS] Tsvector editing functions

Thanks! Fixed and added tests. Thank you! I did some patch cleanup/fix, but I have some doubt with function's names: 1 to_tsvector: # \df to_tsvector List of functions Schema |Name | Result data type | Argument data types | Type

Re: [HACKERS] Endless loop calling PL/Python set returning functions

Alexey Grishchenko writes: > No, my fix handles this well. > In fact, with the first function call you allocate global variables > representing Python function input parameters, call the function and > receive iterator over the function results. Then in a series of

  1   2   >