Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Sun, May 1, 2016 at 3:22 AM, Andrew Dunstan wrote: > > On 04/29/2016 06:11 PM, Merlin Moncure wrote: > > This is a simple matter of removing spaces in the occasional C string >> literal in the serialization routines and adding a json_pretty >> function. >> > > I spent a few hours on this. See

Re: [HACKERS] Add jsonb_compact(...) for whitespace-free jsonb to text

On Fri, Apr 29, 2016 at 3:18 PM, Andrew Dunstan wrote: > > On 04/28/2016 04:29 PM, Alvaro Herrera wrote: > >> >>> Actually we did have someone come up with a patch to "normalize" how >> JSON stuff was output, because our code seems to do it in three >> different, inconsistent ways. And our respo

Re: [HACKERS] Wire protocol compression

On Thu, Apr 21, 2016 at 3:17 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > > > or on Linux TCP/IP stack level. > > > > > > > Yes, but if you want to have both compression and encryption it is > > crucial to apply compression *before* encryption and I don't see how > > this can happ

Re: [HACKERS] Wire protocol compression

On Thu, Apr 21, 2016 at 3:04 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > > I guess since the usual answer for compression was "use what SSL > > provides you for free", it's rather unlikely that someone bothered to > > make a proxy just for that purpose, and really, a proxy is jus

Re: [HACKERS] Wire protocol compression

On Thu, Apr 21, 2016 at 11:07 AM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > > Does it make sense to you guys to discuss compression outside of TLS? > > There are potentially huge bandwidth savings which could benefit both > > WAN and non-WAN scenarios, and decoupling this problem f

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Mon, Apr 11, 2016 at 7:15 PM, Karl O. Pinc wrote: > > Should I submit a regression test or something to ensure > that this usage is officially supported? (A grep for > PQsetSingleRowMode in src/test/ finds no hits.) > Can I assume because it's documented it'll continue to work? Pretty much.

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Fri, Apr 1, 2016 at 7:53 PM, Karl O. Pinc wrote: > > On Fri, 1 Apr 2016 05:57:33 +0200 > "Shulgin, Oleksandr" wrote: > > > On Apr 1, 2016 02:57, "Karl O. Pinc" wrote: > > > > > > I assume there are no questions about supporting a >

Re: [HACKERS] More stable query plans via more predictable column statistics

On Apr 5, 2016 00:31, "Tom Lane" wrote: > > Alex Shulgin writes: > > On Mon, Apr 4, 2016 at 1:06 AM, Tom Lane wrote: > >> I'm inclined to > >> revert the aspect of 3d3bf62f3 that made us work from "d" (the observed > >> number of distinct values in the sample) rather than stadistinct (the > >> e

Re: [HACKERS] SSL indicator in psql prompt

On Apr 4, 2016 17:54, "Robert Haas" wrote: > > On Fri, Apr 1, 2016 at 10:15 AM, Tom Lane wrote: > > Peter Eisentraut writes: > >> I like how browsers show a little lock in the address bar depending on > >> whether SSL is in use. This could be useful in psql as well. Here is a > >> prototype pa

Re: [HACKERS] More stable query plans via more predictable column statistics

On Apr 2, 2016 18:38, "Tom Lane" wrote: > > "Shulgin, Oleksandr" writes: > > On Apr 1, 2016 23:14, "Tom Lane" wrote: > >> Haven't looked at 0002 yet. > > > [crosses fingers] hope you'll have a chance to do that before feature

Re: [HACKERS] More stable query plans via more predictable column statistics

On Apr 1, 2016 23:14, "Tom Lane" wrote: > > "Shulgin, Oleksandr" writes: > > Alright. I'm attaching the latest version of this patch split in two > > parts: the first one is NULLs-related bugfix and the second is the > > "improvement&

Re: [HACKERS] SSL indicator in psql prompt

On Fri, Apr 1, 2016 at 2:52 PM, Peter Eisentraut wrote: > I like how browsers show a little lock in the address bar depending on > whether SSL is in use. This could be useful in psql as well. Here is a > prototype patch. > > Example: > > Put this in .psqlrc: > > \set PROMPT1 '%s%/%R%# ' > > $ p

Re: [HACKERS] PQsendQuery+PQgetResult+PQsetSingleRowMode limitations and support

On Apr 1, 2016 02:57, "Karl O. Pinc" wrote: > > I assume there are no questions about supporting a > similar functionality only without PQsetSingleRowMode, > as follows: Sorry, but I don't see what is your actual question here? Both code examples are going to compile and work, AFAICS. The differ

Re: [HACKERS] unexpected result from to_tsvector

On Wed, Mar 30, 2016 at 10:17 AM, Artur Zakirov wrote: > On 29.03.2016 19:17, Shulgin, Oleksandr wrote: > >> >> Hm, indeed. Unfortunately, it is not quite easy to find "the" new RFC, >> there was quite a number of correcting and extending RFCs issued over &g

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Tue, Mar 15, 2016 at 4:44 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > What I dislike about this POC is all the disruption in libpq, to be >&

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 29, 2016 at 6:24 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > I've just seen that this patch doesn't have a reviewer assigned > anymore... > > I took my name off it because I was busy with other things and didn't > wan

Re: [HACKERS] unexpected result from to_tsvector

On Sun, Mar 20, 2016 at 3:42 PM, Tom Lane wrote: > "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. > > Th

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 15, 2016 at 4:47 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Mar 9, 2016 at 5:28 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > Yes, I now recall that my actual concern was that sample_cnt may >> calc

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 w

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

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 change context name and correct the comment? I didn't suggest to > > change the function name. > > Changed the con

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

On Thu, Mar 17, 2016 at 2:12 AM, Haribabu Kommi wrote: > On Wed, Mar 16, 2016 at 9:49 PM, Shulgin, Oleksandr > wrote: > > > > Some comments: > > > > +/* Context to use with hba_line_callback function. */ > > +typedef struct > > +{ > > + M

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

On Tue, Mar 15, 2016 at 7:23 PM, David Steele wrote: > On 3/3/16 12:16 AM, Haribabu Kommi wrote: > > On Fri, Feb 5, 2016 at 2:29 PM, Haribabu Kommi > wrote: > >> > >> This patch needs to be applied on top discard_hba_and_ident_cxt patch > >> that is posted earlier. > > > > Here I attached a re-b

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

On Tue, Mar 15, 2016 at 6:02 PM, Corey Huinker wrote: > Over the past few months, I've been familiarizing myself with postgres > server side programming in C. > > My attempts to educate myself were slow and halting. The existing server > side programming documentation has some examples, but those

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 9, 2016 at 5:28 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > Yes, I now recall that my actual concern was that sample_cnt may > calculate > > to 0 due to the latest condition above, but that also implies track_cnt > == > > 0, and the

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > What I dislike about this POC is all the disruption in libpq, to be > > honest. > > Yeah, I don't much like that either. But I don't think we can avoid > some refa

Re: [HACKERS] unexpected result from to_tsvector

On Mon, Mar 7, 2016 at 10:46 PM, Artur Zakirov wrote: > Hello, > > On 07.03.2016 23:55, Dmitrii Golub wrote: > >> >> >> Hello, >> >> Should we added tests for this case? >> > > I think we should. I have added tests for teo...@123-stack.net and > 1...@stack.net emails. > > >> 123_reg.ro

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Wed, Feb 10, 2016 at 12:33 AM, Daniel Verite wrote: > Shulgin, Oleksandr wrote: > > > Most importantly, I'd like to learn of better options than storing the > > whole last_result in psql's pset structure. > > I guess that you could, each time

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

On Thu, Mar 10, 2016 at 9:05 PM, Tom Lane wrote: > Gilles Darold writes: > > Then, should I have to use an alternate file to store the information or > > implement a bidirectional communication with the syslogger? > > I'd just define a new single-purpose file $PGDATA/log_file_name > or some such

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 9, 2016 at 1:33 PM, Tomas Vondra wrote: > Hi, > > On Wed, 2016-03-09 at 11:23 +0100, Shulgin, Oleksandr wrote: > > On Tue, Mar 8, 2016 at 8:16 PM, Alvaro Herrera > > wrote: > > > > Also, I can't quite figure out why the "else&qu

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 8, 2016 at 8:16 PM, Alvaro Herrera wrote: > Shulgin, Oleksandr wrote: > > > Alright. I'm attaching the latest version of this patch split in two > > parts: the first one is NULLs-related bugfix and the second is the > > "improvement" part

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 8, 2016 at 9:10 PM, Joel Jacobson wrote: > On Wed, Mar 9, 2016 at 1:25 AM, Shulgin, Oleksandr > wrote: > > Thank you for spending your time to run these :-) > > n/p, it took like 30 seconds :-) > Great! I'm glad to hear it was as easy to use as I hoped

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Mar 8, 2016 at 3:36 PM, Joel Jacobson wrote: > Hi Alex, > > Thanks for excellent research. > Joel, Thank you for spending your time to run these :-) I've ran your queries against Trustly's production database and I can > confirm your findings, the results are similar: > > WITH ... > SE

Re: [HACKERS] More stable query plans via more predictable column statistics

On Mon, Mar 7, 2016 at 6:02 PM, Jeff Janes wrote: > On Mon, Mar 7, 2016 at 3:17 AM, Shulgin, Oleksandr > wrote: > > > > They might get that different plan when they upgrade to the latest major > > version anyway. Is it set somewhere that minor version upgrades sho

Re: [HACKERS] More stable query plans via more predictable column statistics

On Fri, Mar 4, 2016 at 7:27 PM, Robert Haas wrote: > On Thu, Mar 3, 2016 at 2:48 AM, Shulgin, Oleksandr > wrote: > > On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera > > > wrote: > >> Shulgin, Oleksandr wrote: > >> > >> > Alright. I'm

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera wrote: > Shulgin, Oleksandr wrote: > > > Alright. I'm attaching the latest version of this patch split in two > > parts: the first one is NULLs-related bugfix and the second is the > > "improvement" part

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Mar 2, 2016 at 5:46 PM, David Steele wrote: > On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote: > > On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra > > mailto:tomas.von...@2ndquadrant.com>> > wrote: > > > > I think it'd be useful not

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra wrote: > Hi, > > On 02/08/2016 03:01 PM, Shulgin, Oleksandr wrote: > > > ... > >> >> I've incorporated this fix into the v2 of my patch, I think it is >> related closely enough. Also, added corres

Re: [HACKERS] [PATH] Correct negative/zero year in to_date/to_timestamp

On Fri, Feb 26, 2016 at 3:24 PM, Ivan Kartyshov wrote: > The following review has been posted through the commitfest application: > > make installcheck-world: tested, failed > Implements feature: tested, failed > Spec compliant: tested, failed > Documentation:tested

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Mon, Feb 8, 2016 at 5:24 PM, Daniel Verite wrote: > Shulgin, Oleksandr wrote: > > > Added to the Open commitfest: https://commitfest.postgresql.org/9/475/ > > Here's a review. Note that the patch tested and submitted > is not the initial one in the thr

Re: [HACKERS] More stable query plans via more predictable column statistics

On Mon, Jan 25, 2016 at 5:11 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > On Sat, Jan 23, 2016 at 11:22 AM, Tomas Vondra < tomas.von...@2ndquadrant.com> wrote: >> >> >> Overall, I think this is really about deciding when to cut-off the MCV,

Re: [HACKERS] Trivial doc fix in logicaldecoding.sgml

On Thu, Jan 28, 2016 at 9:42 AM, Craig Ringer wrote: > > > On 28 January 2016 at 16:36, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: >> >> On Thu, Jan 28, 2016 at 5:55 AM, Fujii Masao wrote: >>> >>> >>> We should change

Re: [HACKERS] Trivial doc fix in logicaldecoding.sgml

On Thu, Jan 28, 2016 at 5:55 AM, Fujii Masao wrote: > On Wed, Jan 27, 2016 at 7:34 PM, Shulgin, Oleksandr > wrote: > > Hi, > > > > Please find attached a simple copy-paste fix for CREATE_REPLICATION_SLOT > > syntax. > > We should change also START_REPLICA

Re: [HACKERS] Mac OS: invalid byte sequence for encoding "UTF8"

On Wed, Jan 27, 2016 at 10:59 AM, Artur Zakirov wrote: > Hello. > > When a user try to create a text search dictionary for the russian > language on Mac OS then called the following error message: > > CREATE EXTENSION hunspell_ru_ru; > + ERROR: invalid byte sequence for encoding "UTF8": 0xd1 >

[HACKERS] Trivial doc fix in logicaldecoding.sgml

Hi, Please find attached a simple copy-paste fix for CREATE_REPLICATION_SLOT syntax. -- Alex From 05119485a473febe8ffd95103fd7774bc31ee079 Mon Sep 17 00:00:00 2001 From: Oleksandr Shulgin Date: Wed, 27 Jan 2016 11:27:35 +0100 Subject: [PATCH] Fix CREATE_REPLICATION_SLOT syntax in logicaldecoding

Re: [HACKERS] More stable query plans via more predictable column statistics

On Sat, Jan 23, 2016 at 11:22 AM, Tomas Vondra wrote: > Hi, > > On 01/20/2016 10:49 PM, Alvaro Herrera wrote: > >> >> Tom, are you reviewing this for the current commitfest? >> > > While I'm not the right Tom, I've been looking the the patch recently, so > let me post the review here ... > Thank

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Thu, Jan 21, 2016 at 3:25 PM, Robert Haas wrote: > On Wed, Jan 20, 2016 at 2:28 AM, Craig Ringer > wrote: > > It enters COPY BOTH mode before it invokes the startup callback. The > client > > has no way to unilaterally terminate COPY BOTH mode and return to the > normal > > walsender protocol

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Wed, Jan 20, 2016 at 9:26 AM, Craig Ringer wrote: > On 20 January 2016 at 15:50, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > That'd be nice, but probably not totally necessary for streaming > relations. It doesn't really need the slo

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Wed, Jan 20, 2016 at 7:57 AM, Craig Ringer wrote: > On 15 January 2016 at 16:30, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > >> I'd like to propose generic functions (probably in an extension, or in >> core if not possible otherwise) to

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Fri, Jan 15, 2016 at 5:31 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > POC patch attached. Findings: > > 1) Needs an actual slot for all the decode machinery to work (code depends > on MyReplicationSlot being set). > 2) Requires a core patch. >

[HACKERS] Trivial fixes for some IDENTIFICATION comment lines

Hello, I've noticed that in src/backend/replication/logical/reorderbuffer.c, the IDENTIFICATION comment line is incorrect: * IDENTIFICATION * src/backend/replication/reorderbuffer.c By using a simple find+grep command I can see this is also the case for the following files: $ find src -name

Re: [HACKERS] More stable query plans via more predictable column statistics

On Wed, Dec 2, 2015 at 10:20 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane wrote: > >> "Shulgin, Oleksandr" writes: >> > This post summarizes a few weeks of research of ANALYZE statistics &

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Fri, Jan 15, 2016 at 12:09 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Fri, Jan 15, 2016 at 11:08 AM, Simon Riggs > wrote: > >> On 15 January 2016 at 08:30, Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de> wrote: >> >&

Re: [HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

On Fri, Jan 15, 2016 at 11:08 AM, Simon Riggs wrote: > On 15 January 2016 at 08:30, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > >> I'd like to propose generic functions (probably in an extension, or in >> core if not possible otherwise) to

[HACKERS] Stream consistent snapshot via a logical decoding plugin as a series of INSERTs

Hello, I'd like to propose generic functions (probably in an extension, or in core if not possible otherwise) to facilitate streaming existing data from the database *in the same format* that one would get if these would be the changes decoded by a logical decoding plugin. The idea is to use a sn

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Wed, Jan 6, 2016 at 3:02 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > Please find attached a POC patch, using \errverbose for the command name. > Unfortunately, I didn't see a good way to contain the change in psql only > and had to change libp

Re: [HACKERS] Add schema-qualified relnames in constraint error messages.

On Wed, Jan 6, 2016 at 5:06 AM, Jim Nasby wrote: > On 1/5/16 9:16 PM, Tom Lane wrote: > >> Jim Nasby writes: >> >>> FWIW, I suspect very few people know about the verbosity setting (I >>> didn't until a few months ago...) Maybe psql should hint about it the >>> first time an error is reported in

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Tue, Jan 5, 2016 at 11:35 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > >> >> I didn't look in the code yet, but if someone knows off top of t

Re: [HACKERS] Inconsistent error handling in START_REPLICATION command

On Tue, Jan 5, 2016 at 10:39 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > Hackers, > > It looks like there's an inconsistency in error handling during > START_REPLICATION command of replication protocol: > > $ psql postgres://localhost/psycopg2tes

[HACKERS] Inconsistent error handling in START_REPLICATION command

Hackers, It looks like there's an inconsistency in error handling during START_REPLICATION command of replication protocol: $ psql postgres://localhost/psycopg2test?replication=database psql (9.6devel) Type "help" for help. psycopg2test=# IDENTIFY_SYSTEM; systemid | timeline | xlogp

Re: [HACKERS] Re: pglogical_output - a general purpose logical decoding output plugin

On Sun, Jan 3, 2016 at 7:21 PM, Tomasz Rybak wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: not tested > Spec compliant: not tested > Documentation:tested, failed > > Ap

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Mon, Jan 4, 2016 at 6:14 PM, Robert Haas wrote: > On Mon, Jan 4, 2016 at 11:48 AM, Shulgin, Oleksandr > > > > postgres=# select pg_size_bytes(''); > > ERROR: invalid input syntax for type numeric: "" > > I think that's a pretty bad erro

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule wrote: > > 2016-01-04 17:48 GMT+01:00 Shulgin, Oleksandr < oleksandr.shul...@zalando.de>: >> >> On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas wrote: >>> >>> On Mon, Jan 4, 2016 at 10:17 A

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Mon, Jan 4, 2016 at 4:51 PM, Robert Haas wrote: > On Mon, Jan 4, 2016 at 10:17 AM, Pavel Stehule > wrote: > > [ new patch ] > > + case '-': > + ereport(ERROR, > + (errcode(ERRCODE_INVALID_PARAMETER_VALUE), > + errmsg("size cannot be

Re: [HACKERS] pglogical - logical replication contrib module

On Fri, Jan 1, 2016 at 12:34 AM, Petr Jelinek wrote: > Hi, > > I'd like to submit the replication solution which is based on the > pglogical_output [1] module (which is obviously needed for this to compile). > Hi, Impressive stuff! Apparently this depends on a newer, yet-to-be-published versio

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Wed, Dec 30, 2015 at 8:28 PM, Pavel Stehule wrote: > > > 2015-12-30 17:33 GMT+01:00 Robert Haas : > >> On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr >> wrote: >> > I didn't check out earlier versions of this patch, but the latest one >> st

Re: [HACKERS] \x auto and EXPLAIN

On Sun, Jan 3, 2016 at 6:43 PM, Tom Lane wrote: > Andreas Karlsson writes: > > psql's "\x auto" is a nice feature, but it is made much less useful in > > my opinion due to the expanded output format making query plans > > unreadable (and query plans often end up using expanded display due to > >

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

On Wed, Dec 30, 2015 at 4:31 AM, Haribabu Kommi wrote: > > Adding quotes to pg_hba_lookup function makes it different from others. > The issues regarding the same is already discussed in [1]. > > select a.database[1], b.datname from > pg_hba_lookup('postgres','kommih','::1') >

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Tue, Dec 29, 2015 at 7:15 PM, Pavel Stehule wrote: > >> I didn't check out earlier versions of this patch, but the latest one >> still changes pg_size_pretty() to emit PB suffix. >> >> I don't think it is worth it to throw a number of changes together like >> that. We should focus on adding p

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

On Tue, Dec 29, 2015 at 4:15 AM, Haribabu Kommi wrote: > On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr > wrote: > > > > Still this requires a revert of the memory context handling commit for > > load_hba() and load_ident(). I think you can get around the probl

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Tue, Dec 22, 2015 at 10:45 AM, Pavel Stehule wrote: > Hi > > 2015-12-21 16:11 GMT+01:00 Robert Haas : > >> On Sun, Dec 20, 2015 at 4:54 AM, Pavel Stehule >> wrote: >> > new update: >> > >> > 1. unit searching is case insensitive >> > >> > 2. initial support for binary byte prefixes - KiB, MiB

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

On Thu, Dec 24, 2015 at 5:16 AM, Haribabu Kommi wrote: > On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane wrote: > > "Shulgin, Oleksandr" writes: > >> 1. Have you considered re-loading the HBA file upon call to this > function > >> in a local context inst

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

On Wed, Dec 23, 2015 at 12:56 PM, Haribabu Kommi wrote: > On Wed, Dec 23, 2015 at 8:54 PM, Shulgin, Oleksandr > wrote: > > > > 1. Have you considered re-loading the HBA file upon call to this > function in > > a local context instead of keeping it in the backends m

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

On Wed, Dec 16, 2015 at 9:33 AM, Haribabu Kommi wrote: > > Function is changed to accept default values. > > Apart from the above, added a local memory context to allocate the memory > required for forming tuple for each line. This context resets for every > hba line > to avoid consuming unnecess

Re: [HACKERS] psql - -dry-run option

On Thu, Dec 17, 2015 at 9:13 PM, Tom Lane wrote: > > Whether we really need a feature like that isn't clear though; it's not > like it's hard to test things that way now. Stick in a BEGIN with no > COMMIT, you're there. The problem only comes in if you start expecting > the behavior to be bulle

Re: [HACKERS] WIP: bloom filter in Hash Joins with batches

On Tue, Dec 15, 2015 at 11:30 PM, Tomas Vondra wrote: > > Attached is a spreadsheet with results for various work_mem values, and > also with a smaller data set (just 30M rows in the fact table), which > easily fits into memory. Yet it shows similar gains, shaving off ~40% in > the best case, sug

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra wrote: > Hi, > > On 12/01/2015 10:34 AM, Shulgin, Oleksandr wrote: > >> >> I have the plans to make something from this on top of >> pg_stat_statements and auto_explain, as I've mentioned last time. The >>

Re: [HACKERS] More stable query plans via more predictable column statistics

On Fri, Dec 4, 2015 at 6:48 PM, Robert Haas wrote: > On Tue, Dec 1, 2015 at 10:21 AM, Shulgin, Oleksandr > wrote: > > > > What I have found is that in a significant percentage of instances, when > a > > duplicate sample value is *not* put into the MCV list, it does pr

Re: [HACKERS] Logical replication and multimaster

On Thu, Dec 3, 2015 at 8:34 AM, Craig Ringer wrote: > On 3 December 2015 at 14:54, konstantin knizhnik < > k.knizh...@postgrespro.ru> wrote: > >> >> Are there some principle problems with it? In BDR it was handled in >> alternative way, using executor callback. It will be much easier if DDL can >

Re: [HACKERS] More stable query plans via more predictable column statistics

On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > This post summarizes a few weeks of research of ANALYZE statistics > > distribution on one of our bigger production databases with some > real-world > > data and proposes a pat

[HACKERS] More stable query plans via more predictable column statistics

Hi Hackers! This post summarizes a few weeks of research of ANALYZE statistics distribution on one of our bigger production databases with some real-world data and proposes a patch to rectify some of the oddities observed. Introduction We have observed that for certain data sets th

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Dec 1, 2015 at 12:04 AM, Simon Riggs wrote: > On 30 November 2015 at 22:27, Julien Rouhaud > wrote: > > >> I registered as reviewer on this, but after reading the whole thread for >> the second time, it's still not clear to me if the last two submitted >> patches (0001-Add-auto_explain.p

Re: [HACKERS] Revisiting pg_stat_statements and IN() (Was: Re: pg_stat_statements fingerprinting logic and ArrayExpr)

On Wed, Nov 25, 2015 at 9:13 AM, Lukas Fittl wrote: > On Mon, Nov 23, 2015 at 11:53 PM, Peter Geoghegan wrote: > >> One specific justification he gave for not using pg_stat_statements was: >> >> "Doesn’t merge bind vars in IN()" (See slide #11) >> >> I wonder: >> >> * How do other people feel ab

Re: [HACKERS] Erroneous cost estimation for nested loop join

On Mon, Nov 9, 2015 at 11:08 AM, wrote: > > - cost parameter calibration: random_page_cost = 92.89 > This demands some explanation and raises question of value of seq_page_cost parameter -- I don't see anything about it your mail. -- Alex

Re: [HACKERS] pglogical_output - a general purpose logical decoding output plugin

On Mon, Nov 2, 2015 at 1:17 PM, Craig Ringer wrote: > Hi all > > I'd like to submit pglogical_output for inclusion in the 9.6 series as > a contrib. Yay, that looks pretty advanced! :-) Still digesting... -- Alex

Re: [HACKERS] extend pgbench expressions with functions

On Fri, Sep 18, 2015 at 10:21 AM, Fabien COELHO wrote: > > Hello Kyotaro-san, > > My description should have been obscure. Indeed the call tree is >> finite for *sane* expression node. But it makes infinit call for >> a value of expr->etype unknown by both evalDouble and >> evalInt. >> > > Such i

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Mon, Oct 26, 2015 at 10:02 PM, Christopher Browne wrote: > > On 26 October 2015 at 16:25, Peter Eisentraut wrote: > >> On 10/14/15 6:41 AM, Victor Wagner wrote: >> > 1. It is allowed to specify several hosts in the connect string, either >> > in URL-style (separated by comma) or in param=valu

Re: [HACKERS] pg_basebackup and replication slots

On Mon, Oct 26, 2015 at 12:58 PM, Joshua D. Drake wrote: > Hello, > > The fact that pg_basebackup doesn't use replicaiton slots, is that a > technical limitation or just a, "we need a patch"? > I believe it does, but only in master so far, not even in 9.5: http://www.postgresql.org/docs/devel/st

Re: [HACKERS] SuperUser check in pg_stat_statements

On Mon, Oct 19, 2015 at 5:15 PM, rajan wrote: > Hello, > > When monitoring using pg_stat_satements I see that postgres by default > conceals queries executed by other users from the user who is selecting the > pg_stat_statements view. > > I have edited the pg_stat_statements.c by disabling the su

Re: [HACKERS] How to import PostgreSQL 9.2.4 dump to PostgreSQL 9.4.5?

On Thu, Oct 15, 2015 at 11:27 AM, FattahRozzaq wrote: > Hi guys, > > I'm running some test. > > > However, I'm stuck in restoring a PostgreSQL 9.2.4 dump to PostgreSQL > 9.4.5 database. > I'm doing the backup using pg_dump version PostgreSQL 9.2.4 in text > file (SQL dump). > I'm trying to restor

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 7:52 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > This is not a change of the direction, but rather of the approach. > Hitting a process with a signal and hoping it will produce a meaningful > response in all circumstances with

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Wed, Oct 14, 2015 at 12:41 PM, Victor Wagner wrote: > On 2015.08.18 at 07:18:50 +0300, Victor Wagner wrote: > > > Rationale > > = > > > > Since introduction of the WAL-based replication into the PostgreSQL, it > is > > possible to create high-availability and load-balancing clusters. >

Re: [HACKERS] Database schema diff

On Tue, Oct 13, 2015 at 5:48 PM, Michal Novotny < michal.novo...@trustport.com> wrote: > Hi guys, > > I would like to ask you whether is there any tool to be able to compare > database schemas ideally no matter what the column order is or to dump > database table with ascending order of all databa

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 8:34 PM, Simon Riggs wrote: > On 29 September 2015 at 12:52, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > >> Hitting a process with a signal and hoping it will produce a meaningful >> response in all circumstances without d

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 7:01 PM, Simon Riggs wrote: > On 25 September 2015 at 12:13, Shulgin, Oleksandr < > oleksandr.shul...@zalando.de> wrote: > > >> I now believe that use of ProcessInterrupts() in the recently proposed >> design as well as manipulation of p

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 12:57 PM, Andres Freund wrote: > On 2015-09-25 19:13:13 +0200, Shulgin, Oleksandr wrote: > > the auto_explain contrib module. I now propose the most simple thing > > possible in my opinion: a new GUC option for auto_explain. It will make > > every

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Tue, Sep 29, 2015 at 12:28 AM, Jim Nasby wrote: > On 9/18/15 5:05 AM, Shulgin, Oleksandr wrote: > >> >> So this has to be the responsibility of the reply sending backend in the >> end: to create and release the DSM *at some point*. >> > > What's wrong

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 28, 2015 at 7:09 PM, Pavel Stehule wrote: > > 2015-09-28 12:37 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >>> I didn't propose too different solution. There is only one difference - >>> sharing DSM for smaller d

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Fri, Sep 25, 2015 at 7:13 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > Some implementation details: > > For every backend that might be running (MaxBackends) we reserve a > dsm_handle slot in the addins shared memory. When the new option is turned

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Mon, Sep 28, 2015 at 12:05 PM, Pavel Stehule wrote: > > 2015-09-28 12:01 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule >> wrote: >> >> the preparing of content before execution

Re: [HACKERS] On-demand running query plans using auto_explain and signals

On Sun, Sep 27, 2015 at 8:05 AM, Pavel Stehule wrote: the preparing of content before execution is interesting idea, that can be > used more. The almost queries and plans are not too big, so when the size > of content is not too big - less than 1MB, then can be used one DSM for all > backends. >

  1   2   >