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

2016-01-12 Thread Amit Langote
On 2016/01/12 11:28, Vinayak Pokale wrote: > On Jan 12, 2016 11:22 AM, "Amit Langote" > wrote: >> >> On 2016/01/12 10:30, Amit Langote wrote: >>> I'm slightly concerned that the latest patch doesn't incorporate any >>> revisions to the original pgstat interface per

Re: [HACKERS] Some bugs in psql_complete of psql

2016-01-12 Thread Peter Eisentraut
On 12/22/15 4:44 AM, Kyotaro HORIGUCHI wrote: > 1. 0001-Fix-tab-complete-of-CREATE-INDEX.patch > > Fixes completion for CREATE INDEX in ordinary way. This part has been fixed in another thread. Please check whether that satisfies all your issues. > 3.

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Amit Kapila
On Tue, Jan 12, 2016 at 7:24 PM, Andres Freund wrote: > On 2016-01-12 19:17:49 +0530, Amit Kapila wrote: > > Why can't we do it at larger intervals (relative to total amount of writes)? > > To explain, what I have in mind, let us assume that checkpoint interval > > is longer

Re: [HACKERS] PATCH: add pg_current_xlog_flush_location function

2016-01-12 Thread Simon Riggs
On 12 January 2016 at 05:58, Michael Paquier wrote: > On Tue, Jan 12, 2016 at 6:35 AM, Simon Riggs wrote: > > Comments in xlog.c say > > > > "In addition to the shared variable, each backend has a private copy of > > LogwrtResult, which is updated when convenient." > >

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

2016-01-12 Thread Teodor Sigaev
! float4 tmpsml = cnt_sml(qtrg, key, *recheck); /* strange bug at freebsd 5.2.1 and gcc 3.3.3 */ ! res = (*(int *) == *(int *) || tmpsml > nlimit) ? true : false; What's the compiler bug

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

2016-01-12 Thread Aleksander Alekseev
Hello, Álvaro > So you were saying some posts upthread that the new hash tables would > "borrow" AN elements from the freelist then put AN elements back when > too many got unused. Is that idea embodied in this patch? Right. It didn't satisfy "use all memory" requirement anyway. It's better to

Re: [HACKERS] extend pgbench expressions with functions

2016-01-12 Thread Fabien COELHO
Hello Michaël, 1) When precising a negative parameter in the gaussian and exponential functions an assertion is triggered: Assertion failed: (parameter > 0.0), function getExponentialRand, file pgbench.c, line 494. Abort trap: 6 (core dumped) An explicit error is better. Ok for assert ->

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

2016-01-12 Thread Etsuro Fujita
On 2016/01/12 2:36, Alvaro Herrera wrote: I wonder, --- 2166,2213 } /* !* If rel is a base relation, detect whether any system columns are !* requested from the rel. (If rel is a join relation, rel->relid will be !* 0, but there can be no Var in

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Simon Riggs
On 12 January 2016 at 06:35, Michael Paquier wrote: > On Tue, Jan 12, 2016 at 4:57 AM, Simon Riggs > wrote: > > Performance tests for me show that the patch is effective; my results > match > > Jesper's roughly in relative numbers. > > > > My

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Simon Riggs
On 12 January 2016 at 06:41, Michael Paquier wrote: > > + if (log_checkpoints && n > 0) > + ereport(LOG, > + (errmsg("%u two-phase state files were > written " > + "for

Re: [HACKERS] Relation extension scalability

2016-01-12 Thread Dilip Kumar
On Thu, Jan 7, 2016 at 4:53 PM, Andres Freund wrote: > On 2016-01-07 16:48:53 +0530, Amit Kapila wrote: > > I think it's a worthwhile approach to pursue. But until it actually > fixes the problem of leaving around uninitialized pages I don't think > it's very meaningful to do

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
Hi 2016-01-12 11:57 GMT+01:00 Michal Novotny : > Dear PostgreSQL Hackers, > I've discovered an issue with dropping a large table (~5T). I was > thinking drop table is fast operation however I found out my assumption > was wrong. > > Is there any way how to tune it

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Marko Tiikkaja
On 12/01/16 12:17, Pavel Stehule wrote: 2016-01-12 12:14 GMT+01:00 Michal Novotny : Hi Pavel, thanks for the information. I've been doing more investigation of this issue and there's autovacuum running on the table however it's automatically starting even if there

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2016-01-12 Thread Rushabh Lathia
On Thu, Jan 7, 2016 at 6:15 PM, Etsuro Fujita wrote: > On 2016/01/06 18:58, Rushabh Lathia wrote: > >> I started looking at updated patch and its definitely iked the new >> approach. >> > > Thanks for the review! > > With the initial look and test overall things

[HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Dave Cramer
We have an interesting problem, and the reporter has been kind enough to provide logs for which we can't explain. I'd be interested to hear any plausible explanations for a prepared plan suddenly going from 2ms to 60ms for the same input values ? Dave Cramer da...@postgresintl.com

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Dave Cramer
Hi Marko, Interesting so why would it choose a worse plan at that point ? Why would it change at all if the current plan is working well ? Dave Cramer da...@postgresintl.com www.postgresintl.com On 12 January 2016 at 07:15, Marko Tiikkaja wrote: > On 12/01/16 13:00, Dave Cramer

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Amit Kapila
On Tue, Jan 12, 2016 at 12:57 AM, Andres Freund wrote:> > > My theory is that this happens due to the sorting: pgbench is an update > heavy workload, the first few pages are always going to be used if > there's free space as freespacemap.c essentially prefers those. Due to >

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Pavel, thanks for the information. I've been doing more investigation of this issue and there's autovacuum running on the table however it's automatically starting even if there is "autovacuum = off" in the postgresql.conf configuration file. The test of rm 5T file was fast and not taking 24

Re: [HACKERS]WIP: Covering + unique indexes.

2016-01-12 Thread Anastasia Lubennikova
04.01.2016 11:49, David Rowley: On 2 December 2015 at 01:53, Anastasia Lubennikova > wrote: Finally, completed patch "covering_unique_3.0.patch" is here. It includes the functionality discussed above in the thread,

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
2016-01-12 12:14 GMT+01:00 Michal Novotny : > Hi Pavel, > thanks for the information. I've been doing more investigation of this > issue and there's autovacuum running on the table however it's > automatically starting even if there is "autovacuum = off" in the >

[HACKERS] Allow to specify (auto-)vacuum cost limits relative to the database/cluster size?

2016-01-12 Thread Andres Freund
Hi, right now the defaults for autovacuum cost limiting are so low that they regularly cause problems for our users. It's not exactly obvious that any installation above a couple gigabytes definitely needs to change autovacuum_vacuum_cost_delay & autovacuum_vacuum_cost_limit/vacuum_cost_limit.

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Michael Paquier
On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs wrote: > Should we just move the code somewhere just to imply it is generic? Seems > pointless refactoring to me. Er, why not xlogutils.c? Having the 2PC code depending directly on something that is within logicalfuncs.c is

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Albe Laurenz
Vladimir Sitnikov wrote: > Here's the simplified testcase: > https://gist.github.com/vlsi/df08cbef370b2e86a5c1 > > It reproduces the problem in both 9.4.4 and 9.5rc1. > It is reproducible via both psql and pgjdbc. > > I use a single table, however my production case includes a join of > two

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, thanks a lot. I've managed to run DROP TABLE and then cancel process using pg_cancel_backend(autovacuum_pid) and it passed and dropped the 5T table. Thanks a lot! Michal On 01/12/2016 12:37 PM, Andres Freund wrote: > Hi, > > On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: >>

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Andres Freund
On 2016-01-12 19:17:49 +0530, Amit Kapila wrote: > Why can't we do it at larger intervals (relative to total amount of writes)? > To explain, what I have in mind, let us assume that checkpoint interval > is longer (10 mins) and in the mean time all the writes are being done > by bgwriter But

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Vladimir Sitnikov
Here's the simplified testcase: https://gist.github.com/vlsi/df08cbef370b2e86a5c1 It reproduces the problem in both 9.4.4 and 9.5rc1. It is reproducible via both psql and pgjdbc. I use a single table, however my production case includes a join of two tables and the query is like select ... from

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Andres Freund
On 2016-01-12 13:54:21 +0100, Fabien COELHO wrote: > >I measured it in a different number of cases, both on SSDs > >and spinning rust. > > Argh! This is a key point: the sort/flush is designed to help HDDs, and > would have limited effect on SSDs, and it seems that you are showing that > the

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Amit Kapila
On Tue, Jan 12, 2016 at 5:52 PM, Andres Freund wrote: > > On 2016-01-12 17:50:36 +0530, Amit Kapila wrote: > > On Tue, Jan 12, 2016 at 12:57 AM, Andres Freund wrote:> > > > > > > My theory is that this happens due to the sorting: pgbench is an update > > >

Re: [HACKERS]WIP: Covering + unique indexes.

2016-01-12 Thread Jeff Janes
On Tue, Jan 12, 2016 at 8:59 AM, Anastasia Lubennikova wrote: > 08.01.2016 00:12, David Rowley: > > On 7 January 2016 at 06:36, Jeff Janes wrote: >> > But now I see the reason to create non-unique index with included columns - > lack of

Re: [HACKERS] Support for N synchronous standby servers - take 2

2016-01-12 Thread Alvaro Herrera
Michael Paquier wrote: > On Fri, Jan 8, 2016 at 1:53 PM, Kyotaro HORIGUCHI > wrote: > > Hello, > > > > At Mon, 4 Jan 2016 15:29:34 +0900, Michael Paquier > > wrote in > >

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Alvaro Herrera
Michael Paquier wrote: > On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs wrote: > > Should we just move the code somewhere just to imply it is generic? Seems > > pointless refactoring to me. > > Er, why not xlogutils.c? Having the 2PC code depending directly on > something

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Andres Freund
Hi, On 2016-01-11 19:39:14 +, Simon Riggs wrote: > Currently, the patch reuses all of the code related to reading/write state > files, so it is the minimal patch that can implement the important things > for performance. The current patch succeeds in its goal to improve > performance, so I

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

2016-01-12 Thread Alvaro Herrera
Andres Freund wrote: > On 2016-01-11 21:16:42 -0300, Alvaro Herrera wrote: > > Andres, Robert, are you still reviewing this patch? > > I don't think I've signed to - or actually did - reviewed this path. Well, maybe not as such, but you replied to the thread several times, which is why I asked.

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

2016-01-12 Thread Adam Brightwell
> Pushed, with one cosmetic change (update comment on formrdesc). I also > bumped the catversion, but didn't verify whether this is critical. Excellent! Thanks! -Adam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] WIP: Rework access method interface

2016-01-12 Thread Tom Lane
Alvaro Herrera writes: > I just noticed that this patch had remained in Waiting-for-author status > after Alexander had already submitted the updated version of the patch. > I marked it as ready-for-committer, because Petr stated so in the > thread. > Tom, you're

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

2016-01-12 Thread Adam Brightwell
> So this looks like a bugfix that we should backpatch, but on closer > inspection it turns out that we need the rowtype OID to be fixed, which > it isn't unless this: > >> -CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION BKI_WITHOUT_OIDS >> +CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION

Re: [HACKERS] pg_dump dumps event triggers and transforms unconditionally

2016-01-12 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> AFAICT event triggers don't belong to any particular schema, so I'd >> propose that they be dumped only when include_everything is true, >> which is the usual rule for objects that don't belong to any schema. >> >> Transforms

Re: [HACKERS] Removing Functionally Dependent GROUP BY Columns

2016-01-12 Thread Julien Rouhaud
On 01/12/2015 12:07, David Rowley wrote: > On 1 December 2015 at 17:09, Marko Tiikkaja > wrote: > > On 2015-12-01 05:00, David Rowley wrote: > > We already allow a SELECT's target list to contain > non-aggregated columns > in a

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, thanks a lot for your reply. Unfortunately I've found out most it didn't really start DROP TABLE yet and it's locked on autovacuum running for the table and even if I kill the process it's autostarting again and again. Is there any way how to do the DROP TABLE and bypass/disable

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Pavel Stehule
2016-01-12 12:22 GMT+01:00 Marko Tiikkaja : > On 12/01/16 12:17, Pavel Stehule wrote: > >> 2016-01-12 12:14 GMT+01:00 Michal Novotny : >> >> Hi Pavel, >>> thanks for the information. I've been doing more investigation of this >>> issue and there's

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

2016-01-12 Thread Etsuro Fujita
On 2016/01/07 21:45, Etsuro Fujita wrote: On 2016/01/06 18:58, Rushabh Lathia wrote: .) Documentation for the new API is missing (fdw-callbacks). Will add the docs. I added docs for new FDW APIs. Other changes: * Rename relation_has_row_level_triggers to relation_has_row_triggers

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

2016-01-12 Thread Andres Freund
On 2016-01-11 21:16:42 -0300, Alvaro Herrera wrote: > Andres, Robert, are you still reviewing this patch? I don't think I've signed to - or actually did - reviewed this path. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Marko Tiikkaja
On 12/01/16 13:00, Dave Cramer wrote: We have an interesting problem, and the reporter has been kind enough to provide logs for which we can't explain. I'd be interested to hear any plausible explanations for a prepared plan suddenly going from 2ms to 60ms for the same input values ? This is

Re: [HACKERS] extend pgbench expressions with functions

2016-01-12 Thread Michael Paquier
On Tue, Jan 12, 2016 at 5:52 PM, Fabien COELHO wrote: >> 2) When precising a value between 0 and 2, pgbench will loop >> infinitely. For example: >> \set cid debug(random_gaussian(-100, 100, 0)) >> In both cases we just lack sanity checks with PGBENCH_RANDOM, >>

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Michael Paquier
On Tue, Jan 12, 2016 at 5:26 PM, Simon Riggs wrote: > On 12 January 2016 at 06:41, Michael Paquier > wrote: >> >> >> + if (log_checkpoints && n > 0) >> + ereport(LOG, >> + (errmsg("%u two-phase

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
On 2016-01-12 12:17:09 +0100, Pavel Stehule wrote: > 2016-01-12 12:14 GMT+01:00 Michal Novotny : > > > Hi Pavel, > > thanks for the information. I've been doing more investigation of this > > issue and there's autovacuum running on the table however it's > >

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

2016-01-12 Thread Thom Brown
On 8 January 2016 at 05:08, Etsuro Fujita wrote: > On 2016/01/07 21:50, Etsuro Fujita wrote: >> >> On 2016/01/06 20:37, Thom Brown wrote: >>> >>> On 25 December 2015 at 10:00, Etsuro Fujita >>> wrote: Attached is an updated

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
Hi, On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: > thanks a lot for your reply. Unfortunately I've found out most it didn't > really start DROP TABLE yet and it's locked on autovacuum running for > the table and even if I kill the process it's autostarting again and again. Start the DROP

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

2016-01-12 Thread Etsuro Fujita
On 2016/01/12 20:36, Thom Brown wrote: On 8 January 2016 at 05:08, Etsuro Fujita wrote: On 2016/01/06 20:37, Thom Brown wrote: I've run into an issue: *# UPDATE master_customers SET id = 22 WHERE id = 16 RETURNING tableoid::regclass; ERROR: CONTEXT: Remote SQL

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Hi Andres, On 01/12/2016 12:37 PM, Andres Freund wrote: > Hi, > > On 2016-01-12 12:17:01 +0100, Michal Novotny wrote: >> thanks a lot for your reply. Unfortunately I've found out most it didn't >> really start DROP TABLE yet and it's locked on autovacuum running for >> the table and even if I

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Fabien COELHO
Hello Andres, Thanks for the details. Many comments and some questions below. Also, maybe you could answer a question I had about the performance regression you observed, I could not find the post where you gave the detailed information about it, so that I could try reproducing it: what are

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Andres Freund
Hi Michal, This isn't really a question for -hackers, the list for postgres development. -general or -performance would have been more appropriate. On 2016-01-12 11:57:05 +0100, Michal Novotny wrote: > I've discovered an issue with dropping a large table (~5T). I was > thinking drop table is

Re: [HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
On 01/12/2016 12:20 PM, Andres Freund wrote: > On 2016-01-12 12:17:09 +0100, Pavel Stehule wrote: >> 2016-01-12 12:14 GMT+01:00 Michal Novotny : >> >>> Hi Pavel, >>> thanks for the information. I've been doing more investigation of this >>> issue and there's

Re: [HACKERS] checkpointer continuous flushing

2016-01-12 Thread Andres Freund
On 2016-01-12 17:50:36 +0530, Amit Kapila wrote: > On Tue, Jan 12, 2016 at 12:57 AM, Andres Freund wrote:> > > > > My theory is that this happens due to the sorting: pgbench is an update > > heavy workload, the first few pages are always going to be used if > > there's free

[HACKERS] Question about DROP TABLE

2016-01-12 Thread Michal Novotny
Dear PostgreSQL Hackers, I've discovered an issue with dropping a large table (~5T). I was thinking drop table is fast operation however I found out my assumption was wrong. Is there any way how to tune it to drop a large table in the matter of seconds or minutes? Any configuration variable in

[HACKERS] pg_dump dumps event triggers and transforms unconditionally

2016-01-12 Thread Tom Lane
I noticed $subject while trying to fix the extension membership problem Karsten Hilbert complained of last week. I do not think that if I ask for a dump of a single table, that should include event triggers. AFAICT event triggers don't belong to any particular schema, so I'd propose that they be

Re: [HACKERS] pg_dump dumps event triggers and transforms unconditionally

2016-01-12 Thread Alvaro Herrera
Tom Lane wrote: > I noticed $subject while trying to fix the extension membership problem > Karsten Hilbert complained of last week. I do not think that if I ask > for a dump of a single table, that should include event triggers. Ugh, certainly not. > AFAICT event triggers don't belong to any

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Simon Riggs
On 12 January 2016 at 18:14, Andres Freund wrote: > Hi, Thank you for the additional review. > On 2016-01-11 19:39:14 +, Simon Riggs wrote: > > Currently, the patch reuses all of the code related to reading/write > state > > files, so it is the minimal patch that can

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Simon Riggs
On 12 January 2016 at 12:53, Michael Paquier wrote: > On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs > wrote: > > Should we just move the code somewhere just to imply it is generic? Seems > > pointless refactoring to me. > > Er, why not

Re: [HACKERS] WIP: Rework access method interface

2016-01-12 Thread Alvaro Herrera
I just noticed that this patch had remained in Waiting-for-author status after Alexander had already submitted the updated version of the patch. I marked it as ready-for-committer, because Petr stated so in the thread. Tom, you're registered as committer for this patch. Do you have time in the

Re: [HACKERS] Speedup twophase transactions

2016-01-12 Thread Stas Kelvich
My +1 for moving function to xlogutils.c too. Now call to this function goes through series of callbacks so it is hard to find it. Personally I found it only after I have implemented same function by myself (based on code in pg_xlogdump). Stas Kelvich Postgres Professional:

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

2016-01-12 Thread Masahiko Sawada
On Mon, Dec 28, 2015 at 6:38 PM, Masahiko Sawada wrote: > On Mon, Dec 21, 2015 at 11:54 PM, Robert Haas wrote: >> On Mon, Dec 21, 2015 at 3:27 AM, Kyotaro HORIGUCHI >> wrote: >>> Hello, >>> >>> At Fri, 18 Dec 2015

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Vladimir Sitnikov
> I don't know if there is a good solution except disabling server prepared > statements. Why doesn't backend reuse already existing good plan? The plan does account for the skew. Can backend take selectivities from the original bind values? Vladimir -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Pavel Stehule
2016-01-12 16:52 GMT+01:00 Vladimir Sitnikov : > > I don't know if there is a good solution except disabling server > prepared statements. > > Why doesn't backend reuse already existing good plan? > probably good plan is more expensive than wrong plan :( this logic

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Vladimir Sitnikov
VS>>Why doesn't backend reuse already existing good plan? PS>this logic is driven by plan cost, not by plan execution time. It do understand that currently PG replans with $1, $2 and uses default selectivities for that. What I am asking is to make PG aware of "previously used bind values", so it

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

2016-01-12 Thread Alvaro Herrera
Fabien COELHO wrote: > > Here is a two part v12, which: > > part a (refactoring of scripts and their stats): > - fix option checks (-i alone) > - s/repleacable/replaceable/ in doc > - keep small description in doc and help for -S & -N > - fix 2 comments for pg style > - show builtin list if

[HACKERS] blocking the alter role command

2016-01-12 Thread JotaComm
Hello, I would like to know if is it possible to block the following command: ALTER USER myuser PASSWORD; ​My target is allow ​to execute this command from a specific address. Thanks a lot. ​Regards​ -- JotaComm http://jotacomm.wordpress.com

Re: [HACKERS] blocking the alter role command

2016-01-12 Thread Fabrízio de Royes Mello
On Tue, Jan 12, 2016 at 8:32 PM, JotaComm wrote: > > Hello, > > I would like to know if is it possible to block the following command: ALTER USER myuser PASSWORD; > > My target is allow to execute this command from a specific address. > > Thanks a lot. > You should implement

Re: [HACKERS] Weird behavior during CREATE EXTENSION

2016-01-12 Thread Tom Lane
Jim Nasby writes: > I can think of 4 ways to fix this: > 1) Have psql parse the script into separate commands for us. > 2) Pull enough of psql's parsing into the backend code to be able to do #1 > 3) Add *file* line numbers to the output of pg_parse_query() > 4) Have

[HACKERS] Weird behavior during CREATE EXTENSION

2016-01-12 Thread Jim Nasby
This behavior had be quite baffled... ~@decina.local/29760# create extension "trunklet-format" CASCADE; NOTICE: installing required extension "trunklet" NOTICE: installing required extension "variant" CREATE EXTENSION ~@decina.local/29760# create extension "pgxntool-test"; ERROR: syntax

[HACKERS] PGCon 2016 CFP - one week left

2016-01-12 Thread Dan Langille
Hello There is one week left in the PGCon CFP. Details below. Please submit. Thanks. PGCon 2016 will be on 17-21 May 2016 at University of Ottawa. * 17-18 (Tue-Wed) tutorials * 19 & 20 (Thu-Fri) talks - the main part of the conference * 17 & 21 (Wed & Sat) The Developer Unconference & the

Re: [HACKERS]WIP: Covering + unique indexes.

2016-01-12 Thread David Rowley
On 13 January 2016 at 05:59, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 08.01.2016 00:12, David Rowley: > > On 7 January 2016 at 06:36, Jeff Janes wrote: > >> On Tue, Jan 5, 2016 at 11:55 PM, David Rowley >> wrote: >> >

Re: [HACKERS] pg_dump and premature optimizations for objects not to be dumped

2016-01-12 Thread Tom Lane
I wrote: > I looked into Karsten Hilbert's report here > http://www.postgresql.org/message-id/20160108114529.gb22...@hermes.hilbert.loc > of being unable to run pg_upgrade on a database containing the pg_trgm > extension. After some investigation, the problem is explained like this: > ... > The

Re: [HACKERS]WIP: Covering + unique indexes.

2016-01-12 Thread David Rowley
On 13 January 2016 at 06:47, Jeff Janes wrote: > > Why is omit_opclass a separate patch? If the included columns now > never participate in the index ordering, shouldn't it be an inherent > property of the main patch that you can "cover" things without btree > opclasses? >

Re: [HACKERS]WIP: Covering + unique indexes.

2016-01-12 Thread Anastasia Lubennikova
08.01.2016 00:12, David Rowley: On 7 January 2016 at 06:36, Jeff Janes > wrote: On Tue, Jan 5, 2016 at 11:55 PM, David Rowley > wrote: > create table ab (a

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-12 Thread Catalin Iacob
On Tue, Jan 12, 2016 at 5:50 PM, Pavel Stehule wrote: > Error and Fatal exception classes are introduced in my patch - it was Peter' > request (if I remember it well), and now I am thinking so it is not good > idea. Now everybody is confused :). Your patch does: -

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-12 Thread Pavel Stehule
2016-01-12 17:59 GMT+01:00 Catalin Iacob : > On Tue, Jan 12, 2016 at 5:50 PM, Pavel Stehule > wrote: > > Error and Fatal exception classes are introduced in my patch - it was > Peter' > > request (if I remember it well), and now I am thinking so

Re: [HACKERS] count_nulls(VARIADIC "any")

2016-01-12 Thread Marko Tiikkaja
On 03/01/16 22:49, Jim Nasby wrote: In the unit test, I'd personally prefer just building a table with the test cases and the expected NULL/NOT NULL results, at least for all the calls that would fit that paradigm. That should significantly reduce the size of the test. Not a huge deal though...

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-12 Thread Pavel Stehule
2016-01-11 20:11 GMT+01:00 Jim Nasby : > On 1/11/16 12:46 PM, Pavel Stehule wrote: > >> 2016-01-11 19:41 GMT+01:00 Jim Nasby > >: >> >> On 1/11/16 12:33 PM, Pavel Stehule wrote: >> >> 1. break

Re: [HACKERS] Fwd: [JDBC] Re: 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

2016-01-12 Thread Pavel Stehule
2016-01-12 17:01 GMT+01:00 Vladimir Sitnikov : > VS>>Why doesn't backend reuse already existing good plan? > PS>this logic is driven by plan cost, not by plan execution time. > > It do understand that currently PG replans with $1, $2 and uses > default selectivities

Re: [HACKERS] proposal: PL/Pythonu - function ereport

2016-01-12 Thread Catalin Iacob
On Mon, Jan 11, 2016 at 7:33 PM, Pavel Stehule wrote: > I see it. > > it looks like distinguish between Error and SPIError is wrong way. And I > have any other ugly use case. > > If I raise a Error from one PLPythonu function, then in other PLPython > function I'll trap a