Re: [HACKERS] application_name in process name?

2016-07-13 Thread Tom Lane
Mike Blackwell writes: > There are times when it would be useful to have the application_name > connection parameter displayed in the process name - and thus in ps and > pg_top - in addition to the user and database name. > Would there be any downside to this? In a lot

[HACKERS] application_name in process name?

2016-07-13 Thread Mike Blackwell
There are times when it would be useful to have the application_name connection parameter displayed in the process name - and thus in ps and pg_top - in addition to the user and database name. Would there be any downside to this? If it were done, are there any suggestions on how it could be

Re: [HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

2016-07-13 Thread Peter Geoghegan
On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote: > But with upsert/do nothing, this will not work as "needed". > > Would it be possible to introduce a "ON CONFLICT SELECT" argument: > > with _foo as ( > insert into foo(i) values(1) > on conflict select returning id

Re: [HACKERS] Showing parallel status in \df+

2016-07-13 Thread Tom Lane
Peter Eisentraut writes: > On 7/12/16 7:11 PM, Stephen Frost wrote: >> I'm curious how it's useful and in what way \sf does not accomplish what >> you use \df+ for. > One main use is to see multiple related functions next to each other and > compare their source

Re: [HACKERS] Showing parallel status in \df+

2016-07-13 Thread Stephen Frost
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 7/12/16 7:11 PM, Stephen Frost wrote: > > I'm curious how it's useful and in what way \sf does not accomplish what > > you use \df+ for. > > One main use is to see multiple related functions next to each other and > compare their

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tom Lane
Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra > wrote: >> In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced >> his dislike of dense_alloc. I kinda agree with him that introducing "local >>

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Andres Freund
On 2016-07-13 13:37:55 -0400, Tom Lane wrote: > I wonder though if we don't already have another similar use-case in > the ad-hoc "slab allocators" in reorderbuffer.c. That seems to call more for a general slab allocator design, than for something like here. After all, there's plenty of freeing

Re: [HACKERS] Showing parallel status in \df+

2016-07-13 Thread Peter Eisentraut
On 7/12/16 7:11 PM, Stephen Frost wrote: > I'm curious how it's useful and in what way \sf does not accomplish what > you use \df+ for. One main use is to see multiple related functions next to each other and compare their source code. But also because one is used to \df and wants to see

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Andres Freund
On 2016-07-12 10:04:45 -0500, Kevin Grittner wrote: > On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: > > > I'm a bit confused, why aren't we simply adding LSN interlock > > checks for toast? Doesn't look that hard? Seems like a much more > > natural course of fixing

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Andres Freund
On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote: > On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: > > On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: > >> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: > >> >

Re: [HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

2016-07-13 Thread Tom Lane
Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 2:49 AM, Bjørnar Ness wrote: >> But with upsert/do nothing, this will not work as "needed". >> >> Would it be possible to introduce a "ON CONFLICT SELECT" argument: >> >> with _foo as ( >> insert into

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Peter Geoghegan
On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra wrote: > In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced > his dislike of dense_alloc. I kinda agree with him that introducing "local > allocators" may not be the best idea, and as dense_alloc

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tomas Vondra
On 07/13/2016 07:37 PM, Tom Lane wrote: Peter Geoghegan writes: On Wed, Jul 13, 2016 at 7:53 AM, Tomas Vondra wrote: In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced his dislike of dense_alloc. I kinda agree with him

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Robert Haas
On Fri, Jul 8, 2016 at 5:47 AM, Craig Ringer wrote: >> DDL is our standard way of getting things into the system catalogs. >> We have no system catalog metadata that is intended to be populated by >> any means other than DDL. > > Replication slots? (Arguably not catalogs, I

Re: [HACKERS] One process per session lack of sharing

2016-07-13 Thread Robert Haas
On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane wrote: > amatv...@bitec.ru writes: >> Is there any plan to implement "session per thread" or "shared >> sessions between thread"? > > No, not really. The amount of overhead that would add --- eg, the need > for locking on what

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Tom Lane
Robert Haas writes: > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: >> If someone thinks that "gset" is a good idea for pgbench, which I don't, it >> could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG, >> makes more sense

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

2016-07-13 Thread Peter Geoghegan
On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote: > What I don't much like is that it enlarges cluster.out with 200K of > random-looking, hard-to-manually-verify data. May I suggest that > we replace the SELECTs with > > select * from > (select hundred, lag(hundred) over ()

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

2016-07-13 Thread Tom Lane
Peter Geoghegan writes: > On Wed, Jul 13, 2016 at 11:44 AM, Tom Lane wrote: >> If you're good with that adjustment, I'm happy to commit this. > I am happy with the adjustment. Please commit the adjusted patch. Done with minor adjustments.

Re: [HACKERS] \timing interval

2016-07-13 Thread Corey Huinker
On Mon, Jul 11, 2016 at 8:35 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 7/9/16 4:00 PM, Andrew Gierth wrote: > >> How about >> >> Time: 1234567.666 ms (20m 34.6s) >> > > That's similar to what I had in mind, so I'd be happy with that. > > > -- > Peter Eisentraut

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

2016-07-13 Thread Tom Lane
Peter Geoghegan writes: > Attached patch adds a CLUSTER external sort test case to the > regression tests, as discussed. I took a quick look at this patch. > This makes a hardly noticeable difference on the run time of the > CLUSTER tests, at least for me. Consider the

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Robert Haas
On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote: > I note also that replication slots aren't backed up by pg_dump; I see > analogy here and think that at least some parts of logical replication will > be similar and not require DDL at all, just as slots do not. I agree

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Joshua D. Drake
On 07/07/2016 01:01 PM, Robert Haas wrote: There was an unconference session on this topic at PGCon and quite a number of people there stated that they found DDL to be an ease-of-use feature and wanted to have it. Yeah, I haven't meet anyone yet that would like to have: select

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Robert Haas
On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: > If someone thinks that "gset" is a good idea for pgbench, which I don't, it > could be implemented. I think that an "into" feature, like PL/pgSQL & ECPG, > makes more sense for scripting. I agree: I like \into. But: >

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tom Lane
Andres Freund writes: > On 2016-07-13 13:37:55 -0400, Tom Lane wrote: >> We already know that >> that code has performance issues, cf bug #14231, so I suspect there's >> a redesign in its future anyway. > Note that it's not the slab allocators that is having problems, it's >

Re: [HACKERS] Bug in batch tuplesort memory CLUSTER case (9.6 only)

2016-07-13 Thread Peter Geoghegan
On Wed, Jul 13, 2016 at 12:24 PM, Tom Lane wrote: >> I am happy with the adjustment. Please commit the adjusted patch. > > Done with minor adjustments. Thanks. I'm pleased that we found a way forward that addressed every concern. -- Peter Geoghegan -- Sent via

Re: [HACKERS] Header and comments describing routines in incorrect shape in visibilitymap.c

2016-07-13 Thread Robert Haas
On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier wrote: >> OK, that removes comment duplication. Also, what about replacing >> "bit(s)" by "one or more bits" in the comment terms where adapted? >> That's bikeshedding, but that's what this patch is about. > > Translating

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Robert Haas
On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote: > Robert Haas writes: >> On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO wrote: >>> If someone thinks that "gset" is a good idea for pgbench, which I don't, it >>> could be

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Robert Haas
On Thu, Jul 7, 2016 at 8:53 PM, Simon Riggs wrote: >> I thought I sat through, at least, most of it, but you barely gave >> anyone else a chance to talk, which kind of misses the point of an >> unconference. The portion which I attended was not about how to move >> the

Re: [HACKERS] remove checkpoint_warning

2016-07-13 Thread Robert Haas
On Tue, Jul 12, 2016 at 3:19 AM, Magnus Hagander wrote: > +1, this is a useful warning. +1. I'd like to see more people turn log_checkpoints=on, and I often ask customers to do that when they're having systemic performance problems. But this warning regularly alerts me to

[HACKERS] Upcoming PG release schedule

2016-07-13 Thread Tom Lane
Current plans are to produce a 9.6beta3 release next week (ie, wrap Monday Jul 18 for announcement Thursday Jul 21). Keep in mind also that we expect to make routine back-branch update releases on the previously-announced schedule (wrap Monday Aug 8 for announcement Thursday Aug 11). We'll

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread Tom Lane
Alvaro Herrera writes: > Now, I think requesting psql not to split query strings is a good > feature, but having it depend on using \; instead of ; seems way too > obscure. If we want to offer that choice, I propose we do it via some > properly designed mechanism rather

Re: [HACKERS] bug in citext's upgrade script for parallel aggregates

2016-07-13 Thread Andreas Karlsson
On 07/09/2016 05:42 AM, David Rowley wrote: On 30 June 2016 at 03:49, Robert Haas wrote: On Sat, Jun 25, 2016 at 3:44 AM, Andreas Karlsson wrote: On 06/24/2016 01:31 PM, David Rowley wrote: Seems there's a small error in the upgrade script for

Re: [HACKERS] Improving executor performance

2016-07-13 Thread Andres Freund
Hi, On 2016-06-24 16:29:53 -0700, Andres Freund wrote: > 2) Baring 1) tuple deforming is the biggest bottleneck in nearly all >queries I looked at. There's various places we trigger deforming, >most ending in either slot_deform_tuple(), heap_getattr(), >heap_deform_tuple(). > >

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread Alvaro Herrera
David G. Johnston wrote: > On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > > > Although "\;" behavior is not documented, I would have expected both > >>> results to be shown one after the other, or having a an error, but not a > >>> quiet discard. > >> > >> See the

Re: [HACKERS] dumping database privileges broken in 9.6

2016-07-13 Thread Michael Paquier
On Wed, Jul 13, 2016 at 5:18 AM, Stephen Frost wrote: > Attached is a patch to address this. > > After much consideration and deliberation, I went with the simpler > solution to simply dump out the database privileges based on what a new > creation of those privileges would

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2016-07-13 Thread Fabien COELHO
The attached patch provides a solution which ensures the return in the right condition and after the stat collection. The code structure requires another ugly boolean to proceed so as to preserve doing the reconnection between the decision that the return must be done and the place where it

Re: [HACKERS] pgbench - minor fix for meta command only scripts

2016-07-13 Thread Fabien COELHO
Hello Tom, Ok. Here is an updated version, with a better suffix and a simplified comment. Doesn't this break the handling of latency calculations, or at least make the results completely different for the last metacommand than what they would be for a non-last command? It looks like it

[HACKERS] Documentation fix for CREATE FUNCTION

2016-07-13 Thread Albe Laurenz
I just noticed that the documentation for CREATE FUNCTION still mentions that the temporary namespace is searched for functions even though that has been removed with commit aa27977. Attached is a patch to fix that. Yours, Laurenz Albe

Re: [HACKERS] sslmode=require fallback

2016-07-13 Thread Robert Haas
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: > You would think so. > > The default mode of "prefer" is ridiculous in a lot of ways. If you are > using SSL in any shape or form you should simply not use "prefer". That's > really the only answer at this point,

Re: [HACKERS] sslmode=require fallback

2016-07-13 Thread Robert Haas
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: >>> The default mode of "prefer" is ridiculous in a lot of ways. If you are >>> using SSL in any

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Fabien COELHO
Hello Robert, I agree: I like \into. Great! But: SELECT 1, 2 \; SELECT 3; \into one two three I think that's pretty weird. I agree that it is weird, but I do not think that it is bad. Sending a batch of requests is a feature of libpq which is accessible through pgbench by using

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread Fabien COELHO
Hello David, At least we aggree that having a documentation would be an improvement:-) On the second point: - all results should be shown, not just the last one disagree # select 1 ; select 2 ; vs # select 1 \; select 2 ; Result in identical behavior seems undesirable. In both

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Robert Haas
On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra wrote: > I think the MemoryContext API may not be right abstraction for this. +1. The MemoryContext API is little short of an absolute bar to implementing an allocator that works significantly differently than aset.c,

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Andres Freund
On 2016-07-13 16:39:58 -0400, Tom Lane wrote: > Robert Haas writes: > > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra > > wrote: > > What's not clear to me is to what extent slowing down pfree is an > > acceptable price for improving the

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Andres Freund
On 2016-07-13 15:57:02 -0500, Kevin Grittner wrote: > A short answer is that a normal table's heap doesn't go through > systable_getnext_ordered(). That function is used both for cases > where the check should not be made, like toast_delete_datum(), and > cases where it should, like

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Fabien COELHO
Hello Tom, Sending a batch of requests is a feature of libpq which is accessible through pgbench by using "\;", although the fact is not documented. It makes sense for a client to send independent queries together so as to reduce latency. You're putting an awful lot of weight on an

Re: [HACKERS] sslmode=require fallback

2016-07-13 Thread Tom Lane
Robert Haas writes: > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote: >> The default mode of "prefer" is ridiculous in a lot of ways. If you are >> using SSL in any shape or form you should simply not use "prefer". That's >> really the only

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tom Lane
Robert Haas writes: > On Wed, Jul 13, 2016 at 1:10 PM, Tomas Vondra > wrote: > What's not clear to me is to what extent slowing down pfree is an > acceptable price for improving the behavior in other ways. I wonder > how many of the pfree

[HACKERS] unexpected psql "feature"

2016-07-13 Thread Fabien COELHO
Hello devs, Although this is probably a "feature", it is a weird one: $ psql psql (9.6beta2) fabien=# SELECT 1 AS one \; fabien-# SELECT 2 AS two ; two - 2 (1 row) Where is my "1"? Although "\;" behavior is not documented, I would have expected both results to be shown one

[HACKERS] Document that vacuum can't truncate if old_snapshot_threshold >= 0

2016-07-13 Thread Andres Freund
Hi, Currently, if old_snapshot_threshold is enabled, vacuum is prevented from truncating tables: static bool should_attempt_truncation(LVRelStats *vacrelstats) { BlockNumber possibly_freeable; possibly_freeable = vacrelstats->rel_pages - vacrelstats->nonempty_pages; if

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Tom Lane
Fabien COELHO writes: > Sending a batch of requests is a feature of libpq which is accessible > through pgbench by using "\;", although the fact is not documented. It > makes sense for a client to send independent queries together so as to > reduce latency. You're putting

Re: [HACKERS] Header and comments describing routines in incorrect shape in visibilitymap.c

2016-07-13 Thread Michael Paquier
On Thu, Jul 14, 2016 at 4:29 AM, Robert Haas wrote: > On Fri, Jul 8, 2016 at 7:14 AM, Michael Paquier > wrote: >>> OK, that removes comment duplication. Also, what about replacing >>> "bit(s)" by "one or more bits" in the comment terms where

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread Fabien COELHO
Hello Tom, Although "\;" behavior is not documented, I would have expected both results to be shown one after the other, or having a an error, but not a quiet discard. See the documentation for PQexec(): all but the last query result is discarded. Sure. That is developer-level answer to

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread David G. Johnston
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > >> I do not think changing this is appropriate. All you are likely to >> accomplish is breaking code that does what its author wanted. >> > > Hmmm... My 0.02€: Currently this feature is NOT documented, so somehow it >

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread David G. Johnston
On Wed, Jul 13, 2016 at 5:44 PM, Fabien COELHO wrote: > > Hello Tom, > > Although "\;" behavior is not documented, I would have expected both >>> results to be shown one after the other, or having a an error, but not a >>> quiet discard. >>> >> >> See the documentation for

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Petr Jelinek
On 13/07/16 21:06, Robert Haas wrote: We have much to discuss in terms of security, the way it should work and what options to support and a sidetrack into syntax isn't warranted at this early stage. Please lets discuss those important things first, then return to whether DDL makes sense or

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread David G. Johnston
On Wed, Jul 13, 2016 at 4:02 PM, Tom Lane wrote: > Robert Haas writes: > > On Sat, Jul 9, 2016 at 7:52 AM, Fabien COELHO > wrote: > >> If someone thinks that "gset" is a good idea for pgbench, which I > don't, it > >> could be

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread Tom Lane
Fabien COELHO writes: > Hello devs, > Although this is probably a "feature", it is a weird one: > $ psql > psql (9.6beta2) > fabien=# SELECT 1 AS one \; > fabien-# SELECT 2 AS two ; >two > - > 2 > (1 row) > Where is my "1"? > Although "\;"

Re: [HACKERS] pgbench - allow to store select results into variables

2016-07-13 Thread Tom Lane
Robert Haas writes: > On Wed, Jul 13, 2016 at 3:02 PM, Tom Lane wrote: >> I note also that we were talking a couple months ago >> about trying to align psql and pgbench backslash commands more closely. >> This would not be a good step in that direction.

Re: [HACKERS] sslmode=require fallback

2016-07-13 Thread Tom Lane
Robert Haas writes: > On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote: >> Robert Haas writes: >>> Suppose we changed the default to "require". How crazy would that be? >> You mean, aside from the fact that it breaks every

Re: [HACKERS] A Modest Upgrade Proposal

2016-07-13 Thread Christopher Browne
On 13 July 2016 at 15:06, Robert Haas wrote: > On Thu, Jul 7, 2016 at 9:25 PM, Simon Riggs wrote: > > I note also that replication slots aren't backed up by pg_dump; I see > > analogy here and think that at least some parts of logical replication >

Re: [HACKERS] unexpected psql "feature"

2016-07-13 Thread David G. Johnston
On Wed, Jul 13, 2016 at 4:47 PM, Fabien COELHO wrote: > > I would suggest that: > - the \; psql feature should be documented somewhere > ​agreed ​ > - all results should be shown, not just the last one > disagree # select 1 ; select 2 ; ?column? -- 1 (1

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Kevin Grittner
On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund wrote: > On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote: >> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: >>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: On

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

2016-07-13 Thread Michael Paquier
On Wed, Jul 13, 2016 at 10:31 PM, Simon Riggs wrote: > On 12 July 2016 at 23:49, Michael Paquier wrote: >> Hence why not simplifying its interface and remove the force flag? > > Is this change needed as part of a feature? If not, I see no reason

Re: [HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tom Lane
Andres Freund writes: > On 2016-07-13 16:39:58 -0400, Tom Lane wrote: >> I think there's a lot, but I'm afraid most of them are in contexts >> (pun intended) where aset.c already works pretty well, ie it's a >> short-lived context anyway. > FWIW, hacking up the aset/mcxt.c to

Re: [HACKERS] Showing parallel status in \df+

2016-07-13 Thread Robert Haas
On Jul 13, 2016, at 12:25 PM, Stephen Frost wrote: > I disagree. Adding a column is certainly changing the structure, as is > removing one. This certainly hasn't changed my opinion that it's > worthwhile to consider this change, even at this point in the release > cycle,

[HACKERS] Fix typo in postgres_fdw/deparse.c

2016-07-13 Thread Masahiko Sawada
Hi all, Attached patch fixes small typo in contrib/postgres_fdw/deparse.c s/whenver/whenever/g Regards, -- Masahiko Sawada fix_small_typo_in_deparse_c.patch Description: binary/octet-stream -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Improving executor performance - tidbitmap

2016-07-13 Thread Andres Freund
Hi, On 2016-06-24 16:29:53 -0700, Andres Freund wrote: > 4) Various missing micro optimizations have to be performed, for more >architectural issues to become visible. E.g. [2] causes such bad >slowdowns in hash-agg workloads, that other bottlenecks are hidden. One such issue is the

Re: [HACKERS] One process per session lack of sharing

2016-07-13 Thread Craig Ringer
On 14 July 2016 at 03:59, Robert Haas wrote: > I agree that there's not really a plan to implement this, but I don't > agree that connection pooling solves the whole problem. Most people > can't get by with statement pooling, so in practice you are looking at >

Re: [HACKERS] One process per session lack of sharing

2016-07-13 Thread Craig Ringer
On 12 July 2016 at 21:57, wrote: > Hi > > Is there any plan to implement "session per thread" or "shared > sessions between thread"? > As has been noted by others, there isn't any such plan right now. PostgreSQL isn't threaded. It uses a multi-processing

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

2016-07-13 Thread Ashutosh Bapat
> Seems odd to me. Both relations use the same user mapping as before, so > the join should be pushed down. > > Another thing I noticed is that the code in plancache.c would invalidate a > cached plan with a foreign join due to user mapping changes even in the > case where user mappings are

[HACKERS] Constraint merge and not valid status

2016-07-13 Thread Amit Langote
Hi, Consider a scenario where one adds a *valid* constraint on a inheritance parent which is then merged with a child table's *not valid* constraint during inheritance recursion. If merged, the constraint is not checked for the child data even though it may have some. Is that an oversight?

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

2016-07-13 Thread Amit Kapila
On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier wrote: > Hi all, > > As of now UpdateMinRecoveryPoint() is using two arguments: > - lsn, to check if the minimum recovery point should be updated to that > - force, a boolean flag to decide if the update should be

Re: [HACKERS] pg_basebackup wish list

2016-07-13 Thread Amit Kapila
On Tue, Jul 12, 2016 at 10:23 PM, Jeff Janes wrote: > I've been having some adventures with pg_basebackup lately, and had > some suggestions based on those. > > The --help message for pg_basebackup says: > > -Z, --compress=0-9 compress tar output with given compression

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

2016-07-13 Thread Simon Riggs
On 12 July 2016 at 23:49, Michael Paquier wrote: > Hence why not simplifying its interface and remove the force flag? Is this change needed as part of a feature? If not, I see no reason for change. If we all work towards meaningful features the code can be cleaned

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Amit Kapila
On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: > On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: > >> I'm a bit confused, why aren't we simply adding LSN interlock >> checks for toast? Doesn't look that hard? Seems like a much more >> natural

[HACKERS] UPSERT/RETURNING -> ON CONFLICT SELECT?

2016-07-13 Thread Bjørnar Ness
The new upsert feature is a great addition, but in some cases is not as usable as I and seems lots of others would like it to be, take an example with circular references: create table foo ( id serial references bar(foo_id) on delete cascade, i int ); create table bar ( foo_id integer

Re: [HACKERS] Simplifying the interface of UpdateMinRecoveryPoint

2016-07-13 Thread Michael Paquier
On Wed, Jul 13, 2016 at 8:27 PM, Amit Kapila wrote: > On Wed, Jul 13, 2016 at 9:19 AM, Michael Paquier > wrote: >> Hence why not simplifying its interface and remove the force flag? > > One point to note is that the signature and usage of >

Re: [HACKERS] Disable WAL completely - Performance and Persistency research

2016-07-13 Thread Netanel Katzburg
Your patch is very helpful, I'm still checking it on different file-systems. I really liked the idea of using only the edge checkpoints. Thanks. On Mon, Jul 11, 2016 at 9:26 PM, Jeff Janes wrote: > On Thu, Jul 7, 2016 at 1:01 AM, Netanel Katzburg >

Re: [HACKERS] Documentation fix for CREATE FUNCTION

2016-07-13 Thread Tom Lane
Albe Laurenz writes: > I just noticed that the documentation for CREATE FUNCTION still mentions > that the temporary namespace is searched for functions even though that > has been removed with commit aa27977. The example you propose to correct was introduced by that

Re: [HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

2016-07-13 Thread Kevin Grittner
On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila wrote: > On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wrote: >> On Fri, Jul 8, 2016 at 1:52 PM, Andres Freund wrote: >> >>> I'm a bit confused, why aren't we simply adding LSN

Re: [HACKERS] pgbench - compute & show latency consistently

2016-07-13 Thread Fabien COELHO
Hello Peter, number of transactions per client: 1000 -latency average = 15.844 ms +latency average: 15.844 ms tps = 618.764555 (including connections establishing) I think what you have here is that colons separate input parameters and equal signs separate result output. So I think it's

[HACKERS] rethinking dense_alloc (HashJoin) as a memory context

2016-07-13 Thread Tomas Vondra
Hi, In the thread [1] dealing with hashjoin bug introduced in 9.5, Tom voiced his dislike of dense_alloc. I kinda agree with him that introducing "local allocators" may not be the best idea, and as dense_alloc was introduced by me I was playing with the idea to wrap this into a regular