Re: [HACKERS] Performance improvement for joins where outer side is unique

On 9 March 2016 at 13:19, Tom Lane wrote: > I do think that the verbosity this adds to the EXPLAIN output is not > desirable at all, at least not in text mode. Another line for every > darn join is a pretty high price. For me it seems like a good idea to give some sort of indication in EXPLAIN a

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Wed, Mar 9, 2016 at 1:07 AM, Andrew Dunstan wrote: > Michael's patch proposes to replace the use of sed to generate probes.h with > the perl equivalent everywhere. That has the advantage that we keep to one > script to generate probes.h, but it does impose a perl dependency. Good point. It did

Re: [HACKERS] Proposal: RETURNING primary_key()

On 9 March 2016 at 05:40, Igal @ Lucee.org wrote: > On 3/8/2016 12:12 PM, Robert Haas wrote: > >> I agree that some research should be done on how this works in other >> systems, but I think we have a general problem with the server lacking >> certain capabilities that make it easy to implement a

Re: [HACKERS] GCC 6 warning fixes

On 3/8/16 4:44 PM, Robert Haas wrote: > On Mon, Feb 29, 2016 at 4:50 PM, Thomas Munro > wrote: >> On Sat, Feb 20, 2016 at 5:14 PM, Peter Eisentraut wrote: >>> Here are three patches to fix new warnings in GCC 6. >>> >>> 0001 is apparently a typo. >> >> Right, looks like it. Builds and tests OK w

Re: [HACKERS] Declarative partitioning

Hi, On 2016/03/09 9:17, Corey Huinker wrote: >> >> Sorry for replying so late. > No worries! We have jobs to do aside from this. Thanks! >> Everything seemed to go dandy until I tried FOR VALUES (blah , blah], >> where psql wouldn't send the command string without accepting the closing >> paren

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

On 2016/03/09 0:24, Robert Haas wrote: > On Tue, Mar 8, 2016 at 3:02 AM, Amit Langote > wrote: >> Updated versions attached. >> >> * changed st_progress_param to int64 and so did the argument of >> pgstat_progress_update_param(). Likewise changed param1..param10 of >> pg_stat_get_progress_info()'

Re: [HACKERS] Proposal: RETURNING primary_key()

On 9 March 2016 at 04:12, Robert Haas wrote: > I think we have a general problem with the server lacking > certain capabilities that make it easy to implement a high-quality > JDBC driver. And I think it would be good to work on figuring out how > to fix that. There are a few frustrations, to

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

On Wed, Mar 9, 2016 at 12:14 AM, Alvaro Herrera wrote: > Is there anything we can do to short-circuit the wait in the case that > replication happens promptly? A one-minute wait would be acceptable we > terminate it early by checking every second. After sleeping (best debugger ever) on that, act

Re: [HACKERS] Parallel query fails on standby server

On Wed, Mar 9, 2016 at 12:34 AM, Robert Haas wrote: > On Tue, Mar 8, 2016 at 8:23 AM, Michael Paquier > wrote: >> On Tue, Mar 8, 2016 at 9:51 PM, Craig Ringer wrote: >>> On 8 March 2016 at 20:30, Ashutosh Sharma wrote: While testing a parallel scan feature on standby server, it is fou

Re: [HACKERS] Optimizer questions

Konstantin Knizhnik writes: > On 03/08/2016 07:01 AM, Tom Lane wrote: >> I've not spent a lot of time on this, but I think maybe what would make >> sense is to consider both the case where function calculations are >> postponed to after ORDER BY and the case where they aren't, and generate >> Path

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

On 2016/03/09 9:22, Kyotaro HORIGUCHI wrote: >> On Wed, Mar 9, 2016 at 12:24 AM, Robert Haas wrote: >>> This patch has been worked on by so many people and reviewed by so >>> many people that I can't keep track of who should be credited when it >>> gets committed. Could someone provide a list of

Re: [HACKERS] Performance improvement for joins where outer side is unique

David Rowley writes: > [1] http://www.postgresql.org/message-id/8907.1440383...@sss.pgh.pa.us Oh, okay, I had looked at the many changes in the regression outputs and jumped to the conclusion that you were printing the info all the time. Looking closer I see it's only coming out in VERBOSE mode.

Re: [HACKERS] Declarative partitioning

> > > So presently partitions that are unbounded on the lower end aren't > > possible, but that's a creation syntax issue, not an infrastructure > issue. > > Correct? > > In case it wasn't apparent, you can create those: > > FOR VALUES END (upper-bound) [INCLUSIVE] > > which is equivalent to: > > F

[HACKERS] Managing a long-held TupleDesc reference

When PL/Java is told to map a PostgreSQL composite type to a certain Java class, on its first use of the type mapping it calls lookup_rowtype_tupdesc_noerror and then creates a PL/Java UDT structure that retains a reference to the TupleDesc. This seems to be what is leading to a TupleDesc reference

Re: [HACKERS] WIP: Access method extendability

Hi, I went over the latest version of this, here are my notes. create-am.9: + case DO_ACCESS_METHOD: + snprintf(buf, bufsize, +""); + return; Missing the actual description. + appendPQExpBu

Re: [HACKERS] Managing a long-held TupleDesc reference

Chapman Flack writes: > When PL/Java is told to map a PostgreSQL composite type to a certain > Java class, on its first use of the type mapping it calls > lookup_rowtype_tupdesc_noerror and then creates a PL/Java UDT structure > that retains a reference to the TupleDesc. This seems to be what is l

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

Horiguchi-san, Thanks for the review! On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote: >> Updated versions attached. >> >> * changed st_progress_param to int64 and so did the argument of >> pgstat_progress_update_param(). Likewise changed param1..param10 of >> pg_stat_get_progress_info()'s output

Re: [HACKERS] syslog configurable line splitting behavior

On 02/27/2016 04:49 AM, Peter Eisentraut wrote: So I propose the two attached patches that introduce new configuration Boolean parameters syslog_sequence_numbers and syslog_split_lines that can toggle these behaviors. As someone who uses syslog for my servers I find both of these GUCs useful,

Re: [HACKERS] syslog configurable line splitting behavior

On 3/4/16 11:01 AM, Alexander Korotkov wrote: > On Sat, Feb 27, 2016 at 6:49 AM, Peter Eisentraut > wrote: > > Writing log messages to syslog caters to ancient syslog implementations > in two ways: > > - sequence numbers > - line splitting > > While t

Re: [HACKERS] syslog configurable line splitting behavior

On 3/8/16 9:12 PM, Andreas Karlsson wrote: > As someone who uses syslog for my servers I find both of these GUCs > useful, especially when used in combination, and I do not think a > compile time option like suggest by Alexander would be suitable > substitute because then I would need a custom buil

Re: [HACKERS] multivariate statistics v11

On Tue, Mar 8, 2016 at 12:13 PM, Tomas Vondra wrote: > Hi, > > attached is v11 of the patch - this is mostly a cleanup of v10, removing > redundant code, adding missing comments, removing obsolete FIXME/TODOs > and so on. Overall this shaves ~20kB from the patch (not a primary > objective, though)

Re: [HACKERS] Crash with old Windows on new CPU

On 2/12/16 11:24 AM, Christian Ullrich wrote: > Otherwise, it may be time to update the manual (15.6 Supported > Platforms) where it says PostgreSQL "can be expected to work on these > operating systems: [...] Windows (Win2000 SP4 and later), [...]". > Perhaps we could add "except Windows before 7

Re: [HACKERS] syslog configurable line splitting behavior

On 03/09/2016 03:20 AM, Peter Eisentraut wrote: On 3/8/16 9:12 PM, Andreas Karlsson wrote: As someone who uses syslog for my servers I find both of these GUCs useful, especially when used in combination, and I do not think a compile time option like suggest by Alexander would be suitable substit

Re: [HACKERS] fun with "Ready for Committer" patches

On 9 March 2016 at 07:18, Tatsuo Ishii wrote: > > Many of "needs review" state patches already have reviewer(s). Do you > mean we want more reviewers in addition to them for such patches? > Yeah. Personally I'm not too confident about what precisely is required to move a patch from needs-review

Re: [HACKERS] fun with "Ready for Committer" patches

On 2016-03-09 08:18:09 +0900, Tatsuo Ishii wrote: > > It's hard to miss the fact that there are an absolutely breathtaking > > number of patches in this CommitFest - 80! - that are in the "needs > > review" state. We really, really, really need more review to happen - > > Many of "needs review" s

Re: [HACKERS] Recovery test failure for recovery_min_apply_delay on hamster

Michael Paquier wrote: > On Wed, Mar 9, 2016 at 12:14 AM, Alvaro Herrera > wrote: > > Is there anything we can do to short-circuit the wait in the case that > > replication happens promptly? A one-minute wait would be acceptable we > > terminate it early by checking every second. > > After sleep

Re: [HACKERS] Is there a way around function search_path killing SQL function inlining?

On 03/08/2016 01:24 AM, Regina Obe wrote: On Fri, Mar 4, 2016 at 9:29 PM, Regina Obe > wrote: I think the answer to this question is NO, but thought I'd ask. A lot of folks in PostGIS land are suffering from restore issues, materialized view issues etc. because we have functions such as ST_Inte

Re: [HACKERS] VS 2015 support in src/tools/msvc

On Tue, Mar 08, 2016 at 10:32:28PM +0900, Michael Paquier wrote: > Subject: [PATCH 3/4] Fix use of locales for VS 2015 > > lc_codepage is a flag missing from locale.h, causing this code path > introduced in VS 2012 to fail. Perhaps there is a reason for this field > to have been clobbered, but let

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

On Fri, Mar 4, 2016 at 9:16 PM, Jesper Pedersen wrote: > >> >> > I can confirm the marginal speed up in tps due to the new WAL size. > > The TWOPHASE_MAGIC constant should be changed, as the file header has > changed definition, right ? > Thanks for looking at it. I've revised the patch by incre

Re: [HACKERS] Crash with old Windows on new CPU

* Peter Eisentraut wrote: On 2/12/16 11:24 AM, Christian Ullrich wrote: Otherwise, it may be time to update the manual (15.6 Supported Platforms) where it says PostgreSQL "can be expected to work on these operating systems: [...] Windows (Win2000 SP4 and later), [...]". Perhaps we could add "

Re: [HACKERS] Novice Presentation and Company Project

On Thu, Mar 03, 2016 at 12:04:56PM +0100, Eduardo Morras wrote: > My company is developing code for Postgresql for another company and want to > communicate, debate and share the results with the community. > > The objetives are upgrade the network backend and frontend of Postgresql: > > a) Add

Re: [HACKERS] Proposal: "Causal reads" mode for load balancing reads without stale data

On Thu, Mar 3, 2016 at 7:34 PM, Michael Paquier wrote: > WAL replay for 2PC should also > call XLogRequestWalReceiverReply() when needed. Ah yes, I missed this important sentence. I will address that in the next version after some testing. -- Thomas Munro http://www.enterprisedb.com -- Sent

Re: [HACKERS] Optimizer questions

I wrote: > BTW, there's some additional refactoring I had had in mind to do in > grouping_planner to make its handling of the targetlist a bit more > organized; in particular, I'd like to see it using PathTarget > representation more consistently throughout the post-scan-join steps. See 51c0f63e4d

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618”: Permission

On Sun, Oct 18, 2015 at 1:03 AM, Tom Lane wrote: > Amit Kapila writes: >> On Sat, Oct 17, 2015 at 12:07 AM, Robert Haas wrote: >>> Maybe we need to be using PostmasterRandom() rather than random() for >>> the control segment name. > >> +1. Though I think it is better to investigate the actual c

Re: [HACKERS] Pushing down sorted joins

> This patch needs to be rebased. > > Done. > + /* > +* TODO: we should worry about EPQ path but should > that path have > +* pathkeys? I guess, that's not really important > since it's just > +* going to evaluate the join from whole-r

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

> On 2016/03/08 18:19, Kyotaro HORIGUCHI wrote: >> + WHEN 0 THEN 100::numeric(5, 2) >> + ELSE ((S.param3 + 1)::numeric / S.param2 * >> 100)::numeric(5, 2) >> >> This usage of numeric seems overkill to me. > > Hmm, how could this rather be written? OK, ag

Re: [HACKERS] pam auth - add rhost item

On Tue, Mar 8, 2016 at 10:43 PM, Grzegorz Sampolski wrote: > Hi Hari. > To use pam modules you can use whatever backend authentication method > you want. > > This is example configuration: > > Install this library https://github.com/pam-pgsql/pam-pgsql > Create some example database , schema acces

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

On 2016/03/09 10:11, Amit Langote wrote: > The attached revision addresses above and one of Horiguchi-san's comments > in his email yesterday. I fixed one more issue in 0002 per Horiguchi-san's comment. Sorry about so many versions. Thanks, Amit >From 9473230af72e0a0e3b60a8ddf1922698f7f17145 Mon

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

Hi Amit, > -Original Message- > From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp] > Sent: Wednesday, March 09, 2016 4:29 PM > To: Kyotaro HORIGUCHI > Cc: robertmh...@gmail.com; amitlangot...@gmail.com; SPS ポクレ ヴィ > ナヤック(三技術) ; pgsql- > hack...@postgresql.org; SPS 坂野 昌平(三技術) > Sub

<    1   2