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

On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2015-09-18 12:05 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule <pavel.steh...@gmail.com> >> wrote: >

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

On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > This post summarizes a few weeks of research of ANALYZE statistics > > distribution on one of our bigger production data

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

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

On Fri, Dec 4, 2015 at 6:48 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Dec 1, 2015 at 10:21 AM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > What I have found is that in a significant percentage of instances, when > a > &

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

On Wed, Dec 16, 2015 at 8:39 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> 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'

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

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

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

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

On Wed, Dec 30, 2015 at 8:28 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2015-12-30 17:33 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > >> On Mon, Dec 28, 2015 at 8:45 AM, Shulgin, Oleksandr >> <oleksandr.shul...@zalando.de> wrote

[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 |

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/psycopg2test?rep

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 the he

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

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

On Mon, Jan 4, 2016 at 6:03 PM, Pavel Stehule <pavel.steh...@gmail.com> 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 <robertmh...@gmail.com> wrote: >>> >&

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

On Mon, Jan 4, 2016 at 6:14 PM, Robert Haas <robertmh...@gmail.com> 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

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:

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 libpq, ad

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,

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, > +

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 >

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 <kommi.harib...@gmail.com> wrote: > On Wed, Dec 23, 2015 at 8:54 PM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > 1. Have you considered re-loading the HBA file upon call to this > functi

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 <kommi.harib...@gmail.com> wrote: > On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > >> 1. Have yo

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

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 >

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.

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 <kommi.harib...@gmail.com> wrote: > On Mon, Dec 28, 2015 at 9:09 PM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > Still this requires a revert of the memory context handling commit for > > l

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

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:

[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

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 <si...@2ndquadrant.com> 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 n

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 <si...@2ndquadrant.com> > wrote: > >> On 15 January 2016 at 08:30, Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de&g

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 <t...@sss.pgh.pa.us> wrote: > >> "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: >> > This p

[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

[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

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] Add schema-qualified relnames in constraint error messages.

On Mon, Feb 8, 2016 at 5:24 PM, Daniel Verite <dan...@manitou-mail.org> 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 in

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

On Thu, Jan 28, 2016 at 5:55 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, Jan 27, 2016 at 7:34 PM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > Hi, > > > > Please find attached a simple copy-paste fix for CREATE_REPLICATION_SLOT &

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

On Thu, Jan 28, 2016 at 9:42 AM, Craig Ringer <cr...@2ndquadrant.com> 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 <masao.fu...@gmail.com> w

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 >

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. >

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

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

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 <cr...@2ndquadrant.com> 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 n

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 <cr...@2ndquadrant.com> 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

[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

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

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

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

On Wed, Feb 10, 2016 at 12:33 AM, Daniel Verite <dan...@manitou-mail.org> 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

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. >

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

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

On Mon, Mar 14, 2016 at 7:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > What I dislike about this POC is all the disruption in libpq, to be > > honest. > > Yeah, I don't much like that eit

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

On Wed, Mar 9, 2016 at 5:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > Yes, I now recall that my actual concern was that sample_cnt may > calculate > > to 0 due to the latest conditio

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

On Tue, Mar 8, 2016 at 8:16 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> 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 > > &qu

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

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

On Wed, Mar 9, 2016 at 1:33 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> 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 > > <alvhe...@2ndquadrant.com> wrote: > > > &g

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

On Tue, Mar 29, 2016 at 6:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > I've just seen that this patch doesn't have a reviewer assigned > anymore... > > I took my name off it because I was

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 <t...@sss.pgh.pa.us> wrote: > >> "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: >> > Yes, I now reca

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 <t...@sss.pgh.pa.us> wrote: > >> "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: >> > What I disl

Re: [HACKERS] unexpected result from to_tsvector

On Sun, Mar 20, 2016 at 3:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > On Mar 20, 2016 01:09, "Dmitrii Golub" <dmitrii.go...@gmail.com> wrote: > >> Alex, actually subdomain

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

On Fri, Apr 1, 2016 at 7:53 PM, Karl O. Pinc <k...@meme.com> wrote: > > On Fri, 1 Apr 2016 05:57:33 +0200 > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> wrote: > > > On Apr 1, 2016 02:57, "Karl O. Pinc" <k...@meme.com> wrote: >

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?

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 <kommi.harib...@gmail.com> wrote: > On Wed, Mar 16, 2016 at 9:49 PM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > Some comments: > > > > +/* Context to use with hba_line

Re: [HACKERS] unexpected result from to_tsvector

On Mar 20, 2016 01:09, "Dmitrii Golub" <dmitrii.go...@gmail.com> 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 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 <kommi.harib...@gmail.com> wrote: > > On Thu, Mar 17, 2016 at 6:56 PM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > You mean change context name and correct the comment? I didn't sugges

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

On Fri, Mar 4, 2016 at 7:27 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Mar 3, 2016 at 2:48 AM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera <alvhe...@2ndquadrant.com > > > &g

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

On Mon, Mar 7, 2016 at 6:02 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Mon, Mar 7, 2016 at 3:17 AM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > > > They might get that different plan when they upgrade to the latest major > >

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

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

On Wed, Mar 2, 2016 at 5:46 PM, David Steele <da...@pgmasters.net> wrote: > On 3/2/16 11:10 AM, Shulgin, Oleksandr wrote: > > On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra > > <tomas.von...@2ndquadrant.com <mailto:tomas.von...@2ndquadrant.com>> > wrote

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

On Wed, Feb 24, 2016 at 12:30 AM, Tomas Vondra <tomas.von...@2ndquadrant.com > 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 close

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

On Wed, Mar 2, 2016 at 7:33 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> 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 > > &qu

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

On Tue, Mar 8, 2016 at 9:10 PM, Joel Jacobson <j...@trustly.com> wrote: > On Wed, Mar 9, 2016 at 1:25 AM, Shulgin, Oleksandr > <oleksandr.shul...@zalando.de> wrote: > > Thank you for spending your time to run these :-) > > n/p, it took like 30 seconds :

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

Re: [HACKERS] unexpected result from to_tsvector

On Wed, Mar 30, 2016 at 10:17 AM, Artur Zakirov <a.zaki...@postgrespro.ru> 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 an

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

On Apr 1, 2016 23:14, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > Alright. I'm attaching the latest version of this patch split in two > > parts: the first one is NULLs-related b

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

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

On Apr 2, 2016 18:38, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > > "Shulgin, Oleksandr" <oleksandr.shul...@zalando.de> writes: > > On Apr 1, 2016 23:14, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > >> Haven't looked at 0002 yet. > &

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

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,

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,

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

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

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

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

<    1   2