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

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

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] 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 &

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

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

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] 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] 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 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] [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] Don'st start streaming after creating a slot in pg_receivexlog

On Wed, Jul 29, 2015 at 10:02 AM, Heikki Linnakangas wrote: > On 07/29/2015 10:58 AM, Michael Paquier wrote: > >> On Wed, Jul 29, 2015 at 4:51 PM, Heikki Linnakangas >> wrote: >> >>> On 07/29/2015 10:37 AM, Andres Freund wrote: >>> Heikki complained about pg_receivexlog --create-slot s

Re: [HACKERS] [PATCH] Generalized JSON output functions

> > On July 13 I wrote: > > Yes, but I think the plugin is the right place to do it. What is more, >> this won't actually prevent you completely from producing non-ECMAScript >> compliant JSON, since json or jsonb values containing offending numerics >> won't be caught, AIUI. But a fairly simple t

Re: [HACKERS] deparsing utility commands

On Tue, May 12, 2015 at 12:25 AM, Alvaro Herrera wrote: > David Steele wrote: > > > I have reviewed and tested this patch and everything looks good to me. > > It also looks like you added better coverage for schema DDL, which is a > > welcome addition. > > Thanks -- I have pushed this now. > Hi,

Re: [HACKERS] deparsing utility commands

On Wed, Jul 29, 2015 at 12:44 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Tue, May 12, 2015 at 12:25 AM, Alvaro Herrera > wrote: > >> David Steele wrote: >> >> > I have reviewed and tested this patch and everything looks good to me. >

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

On Thu, Aug 13, 2015 at 2:19 AM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Aug 12, 2015 at 4:11 PM, Tom Lane wrote: > >> Peter Geoghegan writes: >> > On Wed, Aug 12, 2015 at 10:30 AM, Alvaro Herrera >> > wrote: >> >> The name count_nulls() suggest an aggregate function to

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

On Thu, Aug 13, 2015 at 9:25 AM, Pavel Stehule wrote: > > > 2015-08-13 9:21 GMT+02:00 Marko Tiikkaja : > >> On 8/13/15 9:18 AM, Shulgin, Oleksandr wrote: >> >>> nnulls() >>> >> >> I think I'd prefer num_nulls() over that. >> >

Re: [HACKERS] replication slot restart_lsn initialization

On Fri, Aug 14, 2015 at 9:54 AM, Andres Freund wrote: > On 2015-08-14 16:44:44 +0900, Michael Paquier wrote: > > Commit 6fcd8851, which is the result of this thread, is not touching > > the replication protocol at all. This looks like an oversight to me: > > we should be a maximum consistent betw

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

On Wed, Aug 19, 2015 at 4:45 PM, ''Victor Wagner *EXTERN*' *EXTERN*' *EXTERN* wrote: > On 2015.08.19 at 15:35:17 +0100, Simon Riggs wrote: > > > > > I think we do need some way of saying that a readonly connection is OK. > So > > I had such thing in my propsal (boolean parameter readonly). > But

Re: [HACKERS] deparsing utility commands

On Thu, Aug 20, 2015 at 4:28 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > Which gets deparsed as: > > ALTER TABLE cwi_test DROP CONSTRAINT cwi_uniq_idx, > ADD CONSTRAINT cwi_replaced_pkey PRIMARY KEY > USING INDEX cwi_replaced_pkey; > > The proble

Re: [HACKERS] psql - better support pipe line

On Wed, Aug 26, 2015 at 5:44 PM, Pavel Stehule wrote: > Hi > > 2015-08-25 17:21 GMT+02:00 Tom Lane : > >> Jim Nasby writes: >> > What I've had problems with is trying to correlate psql specified >> > connection attributes with things like DBI. It would be nice if there >> > was a way to get a fu

Re: [HACKERS] psql - better support pipe line

On Fri, Aug 28, 2015 at 3:29 AM, Jim Nasby wrote: > On 8/27/15 8:37 AM, Pavel Stehule wrote: > >> >> I don't think we can detect and remove the default values from this >> output in a reliable way? >> >> >> This is pretty difficult - any parameter can be important, and hard to >> identify

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On Sat, Aug 29, 2015 at 8:39 AM, Pavel Stehule wrote: > Hi > > currently JSON support NULL value - but we doesn't convert NULL to JSON > correctly > > postgres=# select to_json(NULL::text) IS NULL; > ┌──┐ > │ ?column? │ > ╞══╡ > │ t│ > └──┘ > (1 row) > > probably s

Re: [HACKERS] psql - better support pipe line

On Fri, Aug 28, 2015 at 9:52 PM, Jim Nasby wrote: > On 8/28/15 3:58 AM, Shulgin, Oleksandr wrote: > >> It occurs to me the most flexible thing that could be done here >> would be providing a libpq function that spits out JSON connection >> parameters and ha

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

On Fri, Aug 28, 2015 at 6:10 PM, Teodor Sigaev wrote: > +1 for bringing the jdbc driver URI syntax into libpq, so that all >> interfaces >> can be optionally specified this way. This doesn't preclude the use of >> ipfailover, in fact it might be work well together. If you don't like it, >> don't

Re: [HACKERS] to_json(NULL) should to return JSON null instead NULL

On Sat, Aug 29, 2015 at 3:39 PM, Tom Lane wrote: > Andrew Dunstan writes: > > On 08/29/2015 08:47 AM, Shulgin, Oleksandr wrote: > >> Given there were no loud complaints about this, the current behavior > >> is appropriate for most users, the rest can still work

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

Hello, The other day I've rediscovered the exciting idea of using signals to dump a backend's currently executed query plan, which, it turns out, was already proposed by Pavel and Simon in these threads: http://www.postgresql.org/message-id/flat/cafj8pra-duzkmdtu52ciugb0p7tvri_b8ltjmjfwcnr1lpt...

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

On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund wrote: > On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote: > > Probably using SIGUSR2 would be more appropriate, but I'm not sure if > there > > are other extensions out there that might be already using it for some &g

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

On Aug 29, 2015 7:31 PM, "Pavel Stehule" wrote: > > > > 2015-08-29 18:36 GMT+02:00 Andres Freund : >> >> On 2015-08-29 18:27:59 +0200, Pavel Stehule wrote: >> > 2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr < oleksandr.shul...@zalando.de> >>

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

> > Do you still have the code somewhere around? Did it see production use? >>> >> I sent it to mailing list year ago > > > http://www.postgresql.org/message-id/cafj8praxcs9b8abgim-zauvggqdhpzoarz5ysp1_nhv9hp8...@mail.gmail.com > Ah, thanks! Somehow I've missed this mail. You didn't add the patc

[HACKERS] Adding since-version tags to the docs?

Hello, I often find it pity that our docs are missing any information on since when a certain GUC setting, SQL-level command or function was introduced. Clicking through the "this page in other versions" links at the top of a webpage does help, but you still need to do some guessing (binary searc

Re: [HACKERS] Adding since-version tags to the docs?

On Mon, Aug 31, 2015 at 3:17 PM, Anastasia Lubennikova < a.lubennik...@postgrespro.ru> wrote: > 31.08.2015 14:06, Shulgin, Oleksandr пишет: > > Hello, > > I often find it pity that our docs are missing any information on since > when a certain GUC setting, SQL-level

Re: [HACKERS] Adding since-version tags to the docs?

On Mon, Aug 31, 2015 at 3:30 PM, Andres Freund wrote: > Hi, > > On 2015-08-31 13:06:04 +0200, Shulgin, Oleksandr wrote: > > I often find it pity that our docs are missing any information on since > > when a certain GUC setting, SQL-level command or function was introduce

Re: [HACKERS] Adding since-version tags to the docs?

On Mon, Aug 31, 2015 at 4:01 PM, Tom Lane wrote: > "Shulgin, Oleksandr" writes: > > I often find it pity that our docs are missing any information on since > > when a certain GUC setting, SQL-level command or function was introduced. > > It would be nice if we

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

On Mon, Aug 31, 2015 at 12:35 PM, Pavel Stehule wrote: > >>> >>> http://www.postgresql.org/message-id/cafj8praxcs9b8abgim-zauvggqdhpzoarz5ysp1_nhv9hp8...@mail.gmail.com >>> >> >> Ah, thanks! Somehow I've missed this mail. You didn't add the patch to >> a commitfest back then I think? >> > > I h

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

> > I'd say we should hide the so-designed pg_cmdstatus() interface behind >> more friendly calls like pg_explain_backend() and pg_backend_progress() to >> give some naming examples, to remove the need for magic numbers in the >> second arg. >> > > I had similar idea - this is good enough for start

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

> > I'm not familiar with the shared memory handling, but could we not >> allocate just enough shared memory to fit the data we're going to write >> instead of the fixed 8k? It's not that we cannot know the length of the >> resulting plan text in advance. >> > > the shared memory cannot be reused

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

On Tue, Sep 1, 2015 at 8:12 PM, Andres Freund wrote: > On 2015-09-01 14:07:19 -0400, Robert Haas wrote: > > But I think it's quite wrong to assume that the infrastructure for > > this is available and usable everywhere, because in my experience, > > that's far from the case. > > Especially when t

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

On Tue, Sep 1, 2015 at 7:02 PM, Pavel Stehule wrote: > >> But do we really need the slots mechanism? Would it not be OK to just >> let the LWLock do the sequencing of concurrent requests? Given that we >> only going to use one message queue per cluster, there's not much >> concurrency you can g

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

On Wed, Sep 2, 2015 at 11:16 AM, Pavel Stehule wrote: > > > 2015-09-02 11:01 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Tue, Sep 1, 2015 at 7:02 PM, Pavel Stehule >> wrote: >> >>> >>>> But do we really ne

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

On Wed, Sep 2, 2015 at 2:56 PM, Pavel Stehule wrote: > > > 2015-09-02 12:36 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> On Wed, Sep 2, 2015 at 11:16 AM, Pavel Stehule >> wrote: >> >>> >>> >>>

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

On Wed, Sep 2, 2015 at 3:04 PM, Pavel Stehule wrote: > > >> Well, maybe I'm missing something, but sh_mq_create() will just overwrite >> the contents of the struct, so it doesn't care about sender/receiver: only >> sh_mq_set_sender/receiver() do. >> > > if you create sh_mq from scratch, then you c

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

On Wed, Sep 2, 2015 at 9:00 PM, Robert Haas wrote: > On Wed, Sep 2, 2015 at 4:52 AM, Shulgin, Oleksandr > wrote: > > On Tue, Sep 1, 2015 at 8:12 PM, Andres Freund > wrote: > >> > >> On 2015-09-01 14:07:19 -0400, Robert Haas wrote: > >> > Bu

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

On Wed, Sep 2, 2015 at 3:07 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Sep 2, 2015 at 3:04 PM, Pavel Stehule > wrote: >> >> >>> Well, maybe I'm missing something, but sh_mq_create() will just >>> overwrite the c

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

On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas wrote: > > Maybe someday we should have all that, but I think for right now > that's complicating things unnecessarily. I think the best proposal > so far is to allow the host=X option to be repeated multiple times. > If you repeat the host=X option N

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

On Sep 3, 2015 10:14 PM, "Pavel Stehule" wrote: >>> >>> Please find attached a v3. >>> >>> It uses a shared memory queue and also has the ability to capture plans nested deeply in the call stack. Not sure about using the executor hook, since this is not an extension... >>> >>> The LWLock is used

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

On Sep 3, 2015 7:30 PM, "Robert Haas" wrote: > > All of these objections seem pretty thin to me. I'd accept any of > them as a reason for preferring one alternative over another, but I > don't accept that the presence of a few problems of this magnitude > means we should give up on the feature.

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

On Fri, Sep 4, 2015 at 6:11 AM, Pavel Stehule wrote: > Sorry, but I still don't see how the slots help this issue - could you >> please elaborate? >> > with slot (or some similiar) there is not global locked resource. If I'll > have a time at weekend I'll try to write some prototype. > But you w

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

On Tue, Sep 8, 2015 at 6:58 AM, Pavel Stehule wrote: >> >> But you will still lock on the slots list to find an unused one. How is that substantially different from what I'm doing? > > It is not necessary - you can use similar technique to what it does PGPROC. I am sending "lock free" demo. > > I

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

On Tue, Sep 8, 2015 at 11:49 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > > >> The real problem could be if the process that was signaled to connect > to the message queue never handles the interrupt, and we keep waiting > forever in shm_mq_receive().

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

On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule wrote: > >> Please find attached v4. >> > > It is better > One important thing to notice, and probably deserves a code comment, that any modification of the slot fields done by the info sender backend must be done before actually sending the message

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

On Wed, Sep 9, 2015 at 10:22 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Wed, Sep 9, 2015 at 8:36 AM, Pavel Stehule > wrote: > >> >>> Please find attached v4. >>> >> >> It is better >> > > One important th

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

On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra wrote: > Hi, > > I did a quick initial review of this patch today, so here are my comments > so far: > Hi Tomas, First of all, thanks for the review! - ipcs.c should include utils/cmdstatus.h (the compiler complains > about implicit declaration

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

On Mon, Sep 14, 2015 at 11:53 AM, Tomas Vondra wrote: > > On 09/14/2015 10:23 AM, Shulgin, Oleksandr wrote: > >> On Sat, Sep 12, 2015 at 11:50 AM, Tomas Vondra >> mailto:tomas.von...@2ndquadrant.com>> >> wrote: >> > ... > >> - Attem

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

On Mon, Sep 14, 2015 at 2:11 PM, Tomas Vondra wrote: > >> Now the backend that has been signaled on the second call to >> pg_cmdstatus (it can be either some other backend, or the backend B >> again) will not find an unprocessed slot, thus it will not try to >> attach/detach the queue and the bac

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

> > Well, I didn't attach the updated patch (doing that now). > This time for real. Sorry, it's Monday :-p diff --git a/src/backend/storage/ipc/ipci.c b/src/backend/storage/ipc/ipci.c index 32ac58f..2e3beaf 100644 --- a/src/backend/storage/ipc/ipci.c +++ b/src/backend/storage/ipc/ipci.c @@ -43,6

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

On Mon, Sep 14, 2015 at 3:09 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Sep 14, 2015 at 2:11 PM, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > >> >>> Now the backend that has been signaled on the second call to >>&

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

On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule wrote: > > 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >> I have a radical proposal to remove the need for locking: make the >> CmdStatusSlot struct consist of a mere

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

On Tue, Sep 15, 2015 at 11:00 AM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > On Mon, Sep 14, 2015 at 7:27 PM, Pavel Stehule > wrote: > >> >> 2015-09-14 18:46 GMT+02:00 Shulgin, Oleksandr < >> oleksandr.shul...@zalando.de>: >> >>

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

On Wed, Sep 16, 2015 at 8:07 PM, Pavel Stehule wrote: > > 2015-09-16 16:31 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >> I've added the timeout parameter to the pg_cmdstatus call, and more >> importantly to the sending sid

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

On Thu, Sep 17, 2015 at 12:06 PM, Pavel Stehule wrote: > >> That won't work really well with something like I use to do when testing >> this patch, namely: >> >> postgres=# select pid, array(select pg_cmdstatus(pid, 1, 10)) from >> pg_stat_activity where pid<>pg_backend_pid() \watch 1 >> >> while

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

On Thu, Sep 17, 2015 at 2:14 PM, Robert Haas wrote: > On Wed, Sep 16, 2015 at 10:31 AM, Shulgin, Oleksandr > wrote: > > I've also decided we really ought to suppress any possible ERROR level > > messages generated during the course of processing the status request in &

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

On Thu, Sep 17, 2015 at 5:16 PM, Pavel Stehule wrote: > 2015-09-17 16:46 GMT+02:00 Robert Haas : > >> >> Second, using a shm_mq manipulates the state of the process latch. I >> don't think you can make the assumption that it's safe to reset the >> process latch at any and every place where we ch

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

On Thu, Sep 17, 2015 at 10:13 PM, Robert Haas wrote: > On Thu, Sep 17, 2015 at 11:16 AM, Pavel Stehule > wrote: > > >> Second, using a shm_mq manipulates the state of the process latch. I > >> don't think you can make the assumption that it's safe to reset the > >> process latch at any and ever

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

On Fri, Sep 18, 2015 at 11:25 AM, Pavel Stehule wrote: > 2015-09-18 10:59 GMT+02:00 Shulgin, Oleksandr < > oleksandr.shul...@zalando.de>: > >> >> If we take the per-backend slot approach the locking seems unnecessary >> and there are principally two options:

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

On Fri, Sep 18, 2015 at 12:59 PM, Pavel Stehule 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 >> wrote: >> >>> >>> It should not be true - th

[HACKERS] Calculage avg. width when operator = is missing

Hi Hackers, I've recently stumbled upon a problem with table bloat estimation in case there are columns of type JSON. The quick bloat estimation queries use sum over pg_statistic.stawidth of table's columns, but in case of JSON the corresponding entry is never created by the ANALYZE command due t

Re: [HACKERS] Calculage avg. width when operator = is missing

On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote: > > > > On 09/22/2015 12:16 PM, Shulgin, Oleksandr wrote: >> >> Hi Hackers, >> >> I've recently stumbled upon a problem with table bloat estimation in case there are columns of type JSON. &g

Re: [HACKERS] Calculage avg. width when operator = is missing

On Tue, Sep 22, 2015 at 11:17 PM, Alvaro Herrera wrote: > Shulgin, Oleksandr wrote: > > On Sep 22, 2015 8:58 PM, "Andrew Dunstan" wrote: > > > > Yes, "/revenons/ à /nos moutons/." You can set up text based comparison > > > ops fairly

Re: [HACKERS] Calculage avg. width when operator = is missing

On Tue, Sep 22, 2015 at 11:56 PM, Alvaro Herrera wrote: > Tom Lane wrote: > > > Should we consider this HEAD-only, or a back-patchable bug fix? > > Or perhaps compromise on HEAD + 9.5? > > It looks like a bug to me, but I think it might destabilize approved > execution plans(*), so it may not be

  1   2   >