Re: [HACKERS] Performance degradation in commit ac1d794

On Mon, Mar 21, 2016 at 10:26 AM, Amit Kapila wrote: > > On Mon, Mar 21, 2016 at 10:21 AM, Andres Freund wrote: >> >> >> >> On March 21, 2016 5:12:38 AM GMT+01:00, Amit Kapila < amit.kapil...@gmail.com> wrote: >> >> >The article pointed by you

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

On 20/03/16 05:02, Michael Paquier wrote: On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote: Still to do: the non-perl pieces. The patch to address locales is the sensitive part. The patch from Petr is taking the correct approach though I think that we had better

Re: [HACKERS] Sequence Access Method WIP

On 19/03/16 23:02, Alvaro Herrera wrote: Petr Jelinek wrote: And finally the 0003-gapless-seq is example contrib module that implements dependably and transitionally safe gapless sequence access method. It's obviously slow as it has to do locking and basically serialize all the changes to

Re: [HACKERS] Performance degradation in commit ac1d794

Hi, On 2016-03-21 11:52:43 +1300, Thomas Munro wrote: > The contract that I invented here is that an async-aware parent node > can ask any child node "are you ready?" and get back various answers > including an fd which means please don't call ExecProcNode until this > fd is ready to read. But

Re: [HACKERS] Performance degradation in commit ac1d794

On Mon, Mar 21, 2016 at 10:21 AM, Andres Freund wrote: > > > On March 21, 2016 5:12:38 AM GMT+01:00, Amit Kapila < > amit.kapil...@gmail.com> wrote: > > >The article pointed by you justifies that the way ResetEvent is done by > >patch is correct. I am not sure, but you can

Re: [HACKERS] Performance degradation in commit ac1d794

On March 21, 2016 5:12:38 AM GMT+01:00, Amit Kapila wrote: >The article pointed by you justifies that the way ResetEvent is done by >patch is correct. I am not sure, but you can weigh, if there is a need >of >comment so that if we want enhance this part of code (or

Re: [HACKERS] Choosing parallel_degree

OK cool, thanks. Can we remove the minimum size limit when the per table degree setting is applied? This would help for tables with 2 - 1000 pages combined with a high CPU cost aggregate. Cheers, James Sewell, PostgreSQL Team Lead / Solutions Architect __

Re: [HACKERS] Performance degradation in commit ac1d794

On Sun, Mar 20, 2016 at 7:13 AM, Andres Freund wrote: > > On 2016-03-19 15:43:27 +0530, Amit Kapila wrote: > > On Sat, Mar 19, 2016 at 12:40 PM, Andres Freund wrote: > > > > > > On March 18, 2016 11:52:08 PM PDT, Amit Kapila < amit.kapil...@gmail.com> > >

Re: [HACKERS] multivariate statistics v14

Another skim on 0002: reference.sgml is missing a call to ObjectProperty[] contains a comment that the ACL is "same as relation", but is that still correct, given that now stats may be related to more than one relation? Do we even know what the rules for ACLs on cross-relation stats are? One

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Mon, Mar 21, 2016 at 5:12 AM, Robert Haas wrote: > > On Sun, Mar 20, 2016 at 3:01 AM, Amit Kapila wrote: > > On Sat, Mar 19, 2016 at 7:02 PM, Robert Haas wrote: > >> On Sat, Mar 19, 2016 at 12:28 AM, Amit Kapila

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

Haribabu Kommi wrote: > > Check. > > > > +} lookup_hba_line_context; > > ^ but why TAB here? > > corrected. I am not sure why pg_indent is adding a tab here. It's because lookup_hba_line_context is not listed in typedefs.list. I suggest adding it and all other new typedefs you add, and

Re: [HACKERS] Parallel Aggregate

On 21 March 2016 at 15:48, Alvaro Herrera wrote: > David Rowley wrote: > >> I've rewritten the comment to become: >> >> /* >> * Providing that the estimated size of the hashtable does not exceed >> * work_mem, we'll generate a HashAgg Path, although if we were unable >>

Re: [HACKERS] Parallel Aggregate

David Rowley wrote: > I've rewritten the comment to become: > > /* > * Providing that the estimated size of the hashtable does not exceed > * work_mem, we'll generate a HashAgg Path, although if we were unable > * to sort above, then we'd better generate a Path, so that we at least > * have

Re: [HACKERS] Combining Aggregates

On Sun, Mar 20, 2016 at 2:23 PM, David Rowley wrote: > > I've had a look over this. I had to first base it on the 0005 patch, > as it seemed like the pg_aggregate.h changes didn't include the > serialfn and deserialfn changes, and an OID was being consumed by >

Re: [HACKERS] Improve error handling in pltcl

On 3/17/16 5:46 PM, Tom Lane wrote: Pavel Stehule writes: I'll mark this patch as ready for commiters. I started to look at this patch. It seems to me that the format of the errorCode output is not terribly well designed. ... Maybe there's another way. I've not

Re: [HACKERS] pg_hba_lookup function to get all matching pg_hba.conf entries

On Fri, Mar 18, 2016 at 7:46 PM, Shulgin, Oleksandr wrote: > On Fri, Mar 18, 2016 at 7:53 AM, Haribabu Kommi > wrote: >> >> On Thu, Mar 17, 2016 at 6:56 PM, Shulgin, Oleksandr >> wrote: >> > >> > You mean

Re: [HACKERS] Parallel Aggregate

Hi, On 03/21/2016 12:30 AM, David Rowley wrote: On 21 March 2016 at 09:47, Tomas Vondra wrote: ... I'm not sure changing the meaning of enable_hashagg like this is a good idea. It worked as a hard switch before, while with this change that would not be the case.

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Sun, Mar 20, 2016 at 3:01 AM, Amit Kapila wrote: > On Sat, Mar 19, 2016 at 7:02 PM, Robert Haas wrote: >> On Sat, Mar 19, 2016 at 12:28 AM, Amit Kapila >> wrote: >> > Won't in theory, without patch as well nentries can

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On Sun, Mar 20, 2016 at 1:07 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Mar 18, 2016 at 10:02 AM, Tom Lane wrote: >>> This is mostly a flex/bison hack, isn't it? If you like I'll take it. > >> I would be delighted if you

Re: [HACKERS] Parallel Aggregate

On 21 March 2016 at 09:47, Tomas Vondra wrote: > On 03/20/2016 09:58 AM, David Rowley wrote: >> Thank you for the reviews. The only thing I can think to mention which >> I've not already is that I designed estimate_hashagg_tablesize() to be >> reusable in various

Re: [HACKERS] snapshot too old, configured by time

On Sun, Mar 20, 2016 at 4:25 PM, Peter Geoghegan wrote: > I worry that something weird could happen there. For example, perhaps > the page LSN on what is actually a newly recycled page could be set > such that the backend following a stale right spuriously raises a > "snapshot

Re: [HACKERS] snapshot too old, configured by time

On Thu, Mar 17, 2016 at 2:15 PM, Kevin Grittner wrote: > New patch just to merge in recent commits -- it was starting to > show some bit-rot. Tests folded in with main patch. I haven't read the patch, but I wonder: What are the implications here for B-Tree page recycling by

Re: [HACKERS] multivariate statistics v14

>> Many trailing white spaces found. > > Sorry, haven't noticed that after one of the rebases. Fixed in the > attached v15 of the patch. There are still few of traling spaces. /home/t-ishii/0002-shared-infrastructure-and-functional-dependencies.patch:3792: trailing whitespace.

Re: [HACKERS] WIP: Upper planner pathification

On 3/17/16 9:01 AM, Robert Haas wrote: I think that there are an awful lot of cases where extension authors haven't been able to quite do what they want to do without core changes because they couldn't get control in quite the right place; or they could do it but they had to cut-and-paste a lot

Re: [HACKERS] Performance degradation in commit ac1d794

On Mon, Mar 21, 2016 at 3:46 AM, Andres Freund wrote: > On 2016-03-21 01:31:30 +1300, Thomas Munro wrote: >> I couldn't get the second patch to apply for some reason, > > Weird? Even efter appying the first one first? > > >> but I have been trying out your "latch" branch on

Re: [HACKERS] oldest xmin is far in the past

On 3/19/16 11:32 AM, Tomas Vondra wrote: Hi, On 03/19/2016 06:29 AM, John Snow wrote: There is no any long transaction neither prepared transaction. Can you show us pg_stat_activity? Particularly the xmin values for backends attached to the two databases mentioned in the log (1 and 12451).

[HACKERS] pg_upgrade documentation improvement patch

I was upgrading a cluster, went on the IRC channel to clarify a few things, the following discussion ensued: yuri_niyazov: Hi. I am trying to upgrade to 9.5. The instructions for pg_upgrade include the following bit: [4:35pm] yuri_niyazov: "Again, use compatible initdb flags that match the old

Re: [HACKERS] Weighted Stats

On Sat, Mar 19, 2016 at 05:04:08PM +0100, Tomas Vondra wrote: > Hi, > > On 03/19/2016 07:34 AM, David Fetter wrote: > >On Fri, Mar 18, 2016 at 06:12:12PM -0700, Jeff Janes wrote: > >>On Tue, Mar 15, 2016 at 8:36 AM, David Fetter wrote: > >>> > >>>Please find attached a patch

Re: [HACKERS] extend pgbench expressions with functions

v38 is a simple rebase, trying to keep up-to-date with Tom's work. v39 is yet another rebase: 42 is in sight! -- Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml index c6d1454..4ceddae 100644 --- a/doc/src/sgml/ref/pgbench.sgml +++

Re: [HACKERS] Combining Aggregates

Hi, On 03/20/2016 04:48 AM, David Rowley wrote: On 17 March 2016 at 14:25, Tomas Vondra wrote: On 03/16/2016 12:03 PM, David Rowley wrote: Patch 2: This adds the serial/deserial aggregate infrastructure, pg_dump support, CREATE AGGREGATE changes, and nodeAgg.c

Re: [HACKERS] Performance degradation in commit ac1d794

On Mon, Mar 21, 2016 at 3:46 AM, Andres Freund wrote: > On 2016-03-21 01:31:30 +1300, Thomas Munro wrote: >> I couldn't get the second patch to apply for some reason, > > Weird? Even efter appying the first one first? Ah, I was using patch -p1. I needed to use git am, which

Re: [HACKERS] [patch] Proposal for \crosstabview in psql

Hi 2016-03-19 16:31 GMT+01:00 Alvaro Herrera : > Pavel Stehule wrote: > > > Can I do review? > > Of course. > I did review of last patch. I had to do small changes to run the code due last Tom's changes in psql. Updated patch is attached. The last changes in this

Re: [HACKERS] Parallel Aggregate

Hi, On 03/20/2016 09:58 AM, David Rowley wrote: On 20 March 2016 at 03:19, Robert Haas wrote: On Fri, Mar 18, 2016 at 10:32 PM, David Rowley wrote: Updated patch is attached. I think this looks structurally correct now, and I think it's

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

On 03/20/2016 12:02 AM, Michael Paquier wrote: On Sun, Mar 20, 2016 at 8:06 AM, Andrew Dunstan wrote: Still to do: the non-perl pieces. The patch to address locales is the sensitive part. The patch from Petr is taking the correct approach though I think that we had

Re: [HACKERS] jsonb array-style subscription

> Do you have an updated patch ready? No, I'm afraid it will not be ready for Monday.

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

On Sunday, March 20, 2016, Tom Lane wrote: > > * Allow backslash commands to span lines, probably by adopting the > rule that backslash immediately followed by newline is to be ignored > within a backslash command. This would not be compatible with psql, > though, at least

Re: [HACKERS] pgbench - allow backslash-continuations in custom scripts

Robert Haas writes: > On Fri, Mar 18, 2016 at 10:02 AM, Tom Lane wrote: >> This is mostly a flex/bison hack, isn't it? If you like I'll take it. > I would be delighted if you would. I've committed changes equivalent to Horiguchi-san's 0001 and 0002

[HACKERS] Gendered language in source

-Hackers, The twitter verse has picked up on the fact that some of the comments in our source code are gendered. We may want to apply a patch for that. Sincerely, JD -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL

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

On Wed, Mar 16, 2016 at 6:44 AM, Rahila Syed wrote: >>Sorta. Committed after renaming what you called heap blocks vacuumed >>back to heap blocks scanned, adding heap blocks vacuumed, removing the >>overall progress meter which I don't believe will be anything close to

Re: [HACKERS] PATCH: index-only scans with partial indexes

Hi, On 03/09/2016 09:29 AM, Kyotaro HORIGUCHI wrote: Hello, thank you for the comments. The new v8 patch is attched. I've looked at v8, and I do have a few minor comments: 1) indxpath.c uses get_plan_rowmark without including optimizer/prep.h so the compiler complains about missing

Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used

* Christian Ullrich wrote: * From: Magnus Hagander [mailto:mag...@hagander.net] I don't like the name "real_realm" as a parameter name. I'm wondering if it might be better to reverse the meaning, and call it sspi_netbios_realm (and then change the default to on, to be backwards compatible).

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-03-18 05:56:41 -0400, Robert Haas wrote: > >> 0 at the top of the loop and skip it forthwith if so. > > > > You mean in WaitEventSetWait()? There's > > else if (rc == 0) > > { > > break; > > } > > which is the timeout

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Fri, Mar 18, 2016 at 7:22 PM, Rajkumar Raghuwanshi wrote: > Hi, > > I am testing postgres_fdw join pushdown feature for PostgreSQL 9.6 DB, and I > observed below issue. > > Observation: If do a left outer join on foreign tables more than two times. > It

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-03-21 01:31:30 +1300, Thomas Munro wrote: > I couldn't get the second patch to apply for some reason, Weird? Even efter appying the first one first? > but I have been trying out your "latch" branch on some different OSs > and porting some code that does a bunch of waiting on many

Re: [HACKERS] unexpected result from to_tsvector

"Shulgin, Oleksandr" writes: > On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: >> Alex, actually subdomain can start with digit, > Not according to the RFC you have linked to. The powers-that-be relaxed that some time ago; I assume there's a

Re: [HACKERS] [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator

Hi, On 03/01/2016 05:08 PM, Roma Sokolov wrote: On 27 Feb 2016, at 03:46, Euler Taveira wrote: Because it is not a common practice to test catalog dependency on separate tests (AFAICS initial catalogs are tested with oidjoins.sql). Also, your test case is too huge for

Re: [HACKERS] [COMMITTERS] pgsql: Improve memory management for external sorts.

On 2016-03-18 14:40:33 -0400, Robert Haas wrote: > > Oops. Thanks for the report. Does this fix it? > > Trying again to attach the patch. Yes, that removes the warning, and looks correct. Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: Pushdown target list below gather node (WAS Re: [HACKERS] WIP: Upper planner pathification)

On Wed, Mar 16, 2016 at 12:36 PM, Tom Lane wrote: > Robert Haas writes: > > That doesn't update the cost of the subpath, which it probably needs to > > do. I wonder if this shouldn't be implemented by recursing. > > > if (IsA(path, GatherPath) &&

Re: [HACKERS] Small patch: fix double variable initializations in policy.c

Aleksander Alekseev writes: > I'm quite sure that there is no need to initialize these variables > twice. First patch fixes this. Also I discovered that policy.c is not > properly pgindent'ed. Second patch fixes this too. Applied the first patch --- though I chose to

Re: [HACKERS] [PATCH] Phrase search ported to 9.6

On 2/29/16 10:33 AM, Artur Zakirov wrote: > Conclusion > -- > > This patch is large and it needs more research. I will be reviewing it > and will give another notes later. This thread has not had a response from the authors or new patch in more than two weeks. Please post something

Re: [HACKERS] FIX : teach expression walker about RestrictInfo

Robert Haas writes: > On Wed, Apr 29, 2015 at 12:33 PM, Tomas Vondra > wrote: >> On 04/29/15 18:26, Tom Lane wrote: >>> But there are basic reasons why expression_tree_walker should not try >>> to deal with RestrictInfos; the most obvious one

Re: [HACKERS] [GENERAL] Request - repeat value of \pset title during \watch interations

On Sat, Mar 19, 2016 at 11:42 PM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 1:40 AM, David G. Johnston > wrote: >> Adding -hackers for consideration in the Commitfest. > > I don't much like how this patch uses the arbitrary constant 50 in no

Re: [HACKERS] Choosing parallel_degree

On 16/03/2016 17:16, Robert Haas wrote: > On Tue, Mar 15, 2016 at 8:26 PM, Julien Rouhaud > > wrote: > > On 15/03/2016 21:12, Robert Haas wrote: > > On Mon, Mar 14, 2016 at 9:25 PM, David Rowley > >

Re: [HACKERS] Parallel Aggregate

On Fri, Mar 18, 2016 at 9:16 AM, David Rowley wrote: > I've attached an updated patch. This looks substantially better than earlier versions, although I haven't studied every detail of it yet. + * Partial aggregation requires that each aggregate does not have a

Re: [HACKERS] Performance degradation in commit ac1d794

On Sun, Mar 20, 2016 at 5:14 PM, Andres Freund wrote: > On 2016-03-19 18:45:36 -0700, Andres Freund wrote: >> On 2016-03-19 16:44:49 +0530, Amit Kapila wrote: >> > On Fri, Mar 18, 2016 at 1:34 PM, Andres Freund wrote: >> > > >> > > >> > > Attached is a

Re: [HACKERS] Choosing parallel_degree

On 18 March 2016 at 10:13, James Sewell wrote: > This does bring up an interesting point I don't quite understand though. If I > run parallel agg on a table with 4 rows with 2 workers will it run on two > workers (2 rows each) or will the first one grab all 4 rows? It

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-03-17 09:01:36 -0400, Robert Haas wrote: > > * Right now the caller has to allocate the WaitEvents he's waiting for > > locally (likely on the stack), but we also could allocate them as part > > of the WaitEventSet. Not sure if that'd be a benefit. > > I'm not seeing this. What do you

[HACKERS] fd.c: flush data problems on osx

Hi Current implementation of pg_flush_data when called with zero offset and zero nbytes is assumed to flush all file. In osx it uses mmap with these arguments, but according to man: "[EINVAL] The len argument was negative or zero. Historically, the system call would not return an

Re: [HACKERS] typmod is always -1

On 3/17/16 7:40 PM, Tom Lane wrote: Chapman Flack writes: It seems that a typmod can only be used restrict the set of possible values of the unmodified type (as clearly seen in the language "length conversion cast", since certainly a typmod allowing { string | length < N

Re: [HACKERS] Parallel Aggregate

On 20 March 2016 at 03:19, Robert Haas wrote: > On Fri, Mar 18, 2016 at 10:32 PM, David Rowley > wrote: >> Updated patch is attached. > > I think this looks structurally correct now, and I think it's doing > the right thing as far as

[HACKERS] oldest xmin is far in the past

Hi everyone! Trying to make VACUUM FREEZE on PG instance and keep getting this error: 2016-03-18 05:56:51 UTC 46750 WARNING: oldest xmin is far in the past 2016-03-18 05:56:51 UTC 46750 HINT: Close open transactions soon to avoid wraparound problems. 2016-03-18 05:56:51 UTC 46750 DEBUG:

Re: [HACKERS] WIP: Access method extendability

I don't see any objection, is consensus reached? I'm close to comiit that... I did only cursory review on the bloom contrib module and don't really have complaints there, but I know you can review that one. I'd like the English of the generic_xlog.c description improved but I won't get to it

Re: [HACKERS] Make primnodes.h gender neutral

> On Mar 17, 2016, at 12:31 PM, Joshua D. Drake wrote: > > Per the twitter verse, here is an updated version of primnodes.h > -- > Command Prompt, Inc. http://the.postgres.company/ >+1-503-667-4564 > PostgreSQL Centered full

Re: [HACKERS] proposal: function parse_ident

2016-03-18 16:26 GMT+01:00 Teodor Sigaev : > I hope so the messages are ok now. Few more regress tests added. >> > > Thank you, committed. Thank you very much Pavel > > > -- > Teodor Sigaev E-mail: teo...@sigaev.ru >

Re: [HACKERS] [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check

I wrote: > I had almost gotten to the point of being willing to commit this patch > when I noticed that it fails to fix the originally-complained-of-problem: > ... > AFAICS the only way that we can avoid a dump/reload hazard is to tighten > up the allowed range of timestamps by at least one day,

Re: [HACKERS] unexpected result from to_tsvector

On Mar 20, 2016 01:09, "Dmitrii Golub" wrote: > > 2016-03-14 16:22 GMT+03:00 Shulgin, Oleksandr < oleksandr.shul...@zalando.de>: >> >> In fact, the 123-yyy.zzz domain is not valid either according to the RFC (subdomain can't start with a digit), but since we already allow

Re: Pushdown target list below gather node (WAS Re: [HACKERS] WIP: Upper planner pathification)

Robert Haas writes: > On Wed, Mar 16, 2016 at 2:02 PM, Tom Lane wrote: >> Looks pretty close. One point is that if we do end up using a Result >> node, then the parent GatherPath does not get charged for the Result >> node's cpu_per_tuple overhead.

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

On 16 March 2016 at 23:32, David Steele wrote: > On 3/10/16 1:24 PM, Corey Huinker wrote: > >> New patch for Alvaro's consideration. >> >> Very minor changes since the last time, the explanations below are >> literally longer than the changes: >> - Rebased,

Re: [HACKERS] Patch: fix lock contention for HASHHDR.mutex

On Sat, Mar 19, 2016 at 7:02 PM, Robert Haas wrote: > > On Sat, Mar 19, 2016 at 12:28 AM, Amit Kapila wrote: > > Won't in theory, without patch as well nentries can overflow after running > > for very long time? I think with patch it is more prone

Re: [HACKERS] max_parallel_degree context level

On 12 February 2016 at 04:55, Robert Haas wrote: > On Thu, Feb 11, 2016 at 10:32 AM, Simon Riggs wrote: >> Is it slower if you request N workers, yet only 1 is available? > > I sure hope so. There may be some cases where more workers are slower >

Re: [HACKERS] pgbench stats per script & other stuff

Hello Jeff, So I wanted to do something like: for f in `seq 0 5 100`; do pgbench -T 180 -c8 -j8 -b tpcb-like@$f -b select-only@100 done; But, I'm not allowed to specify a weight of zero. Indeed. I did not envision such a use case, but it is quite legitimate and interesting! I would hope

Re: [HACKERS] Performance degradation in commit ac1d794

On 2016-03-17 09:40:08 -0400, Robert Haas wrote: > On Thu, Mar 17, 2016 at 9:01 AM, Robert Haas wrote: > > I'll look at 0005 next, but thought I would send these comments along first. > > 0005: This is obviously very much WIP, but I think the overall > direction of it is

Re: [HACKERS] Show dropped users' backends in pg_stat_activity

Robert Haas writes: > Gee, I would have expected the DROP to be blocked until the user > disconnected, like we do for DROP DATABASE. Making that race-condition-free would require some notion of a lock on roles, I think. Seems pretty messy compared to the amount of actual