Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Sat, Sep 30, 2017 at 12:42 AM, Robert Haas wrote: > On Wed, Sep 27, 2017 at 11:15 PM, Masahiko Sawada > wrote: >> I think that making a resolver process have connection caches to each >> foreign server for a while can reduce the overhead of connection to >> foreign servers. These connections

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

On Mon, Oct 2, 2017 at 8:13 AM, Daniel Gustafsson wrote: > I’ve moved this to the next CF, but since this no longer applies cleanly I’ve > reset it to Waiting for author. Thanks Daniel for the reminder. Attached are rebased patches. This thing rots easily... -- Michael 0001-Change-detection-of

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Mon, Oct 2, 2017 at 1:43 PM, Bossart, Nathan wrote: > On 9/29/17, 9:33 AM, "Bossart, Nathan" wrote: >> Here's a version without the logging changes in vacuum_rel() and >> analyze_rel(). I’ll look into submitting those in the next commitfest. > > Since get_rel_oids() was altered in 19de0ab2, h

Re: [HACKERS] Walsender timeouts and large transactions

Hello Sokolov. At Fri, 29 Sep 2017 15:19:23 +0300, Sokolov Yura wrote in > I don't want to make test to lasts so long and generate so many data. > That is why I used such small timeouts for tests. I understand your point, but still *I* think such a short timeout is out of expectation by design

Re: [HACKERS] Logging idle checkpoints

On 2017-10-02 07:43:31 +0900, Michael Paquier wrote: > On Mon, Oct 2, 2017 at 7:41 AM, Andres Freund wrote: > > On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: > >> On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > >> > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > >> > I'd be ok w

Re: [HACKERS] [PATCH] Off-by-one error in logical slot resource retention

On 2 October 2017 at 05:27, Daniel Gustafsson wrote: > > On 15 Sep 2017, at 13:26, Daniel Gustafsson wrote: > > > >> On 01 Sep 2017, at 14:28, Aleksander Alekseev < > a.aleks...@postgrespro.ru> wrote: > >> > >> The following review has been posted through the commitfest application: > >> make in

Re: [HACKERS] pg_prepared_xact_status

On 30 September 2017 at 14:10, konstantin knizhnik < k.knizh...@postgrespro.ru> wrote: > So I do not see any troubles caused by adding this functions. And it can > really be helpful for DBA in some cases. > If it's self-contained and exposes existing functionality, then I'm not opposed, I just d

Re: [HACKERS] pg_prepared_xact_status

On 2 October 2017 at 08:09, Robert Haas wrote: > On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik > wrote: > > txid_status() also not always be able to return status of transaction > (if wraparound happen). > > But it is still considered as one of the key features of 10 (transaction > tracea

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

Thanks for the objection with clear reasoning. For clarity, I first proposed to prohibit servers of different versions from sharing same tablespace directory. https://www.postgresql.org/message-id/20170406.160844.120459562.horiguchi.kyot...@lab.ntt.co.jp And I had -1 that it is just a reverting

Re: [HACKERS] path toward faster partition pruning

On 2017/09/30 1:28, Robert Haas wrote: > On Thu, Sep 28, 2017 at 5:16 AM, David Rowley > wrote: >> I'd imagine, for >> each partition key, you'd want to store a Datum with the minimum and >> maximum possible value based on the quals processed. If either the >> minimum or maximum is still set to NU

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

> On 06 Sep 2017, at 08:42, Fabien COELHO wrote: > > Hello Alik, > > Applies, compiles, works for me. > > Some minor comments and suggestions. > > Two typos: > - "usinng" -> "using" > - "a rejection method used" -> "a rejection method is used" > > I'm not sure of "least_recently_used_i", this

Re: [HACKERS] Small patch for pg_basebackup argument parsing

> On 18 Sep 2017, at 23:18, Pierre Ducroquet wrote: > > On Monday, September 18, 2017 5:13:38 PM CEST Tom Lane wrote: >> Ryan Murphy writes: >>> Looked thru the diffs and it looks fine to me. >>> Changing a lot of a integer/long arguments that were being read directly >>> via atoi / atol to be r

Re: [HACKERS] Optional message to user when terminating/cancelling backend

> On 28 Sep 2017, at 14:55, Yugo Nagata wrote: > > On Sun, 3 Sep 2017 22:47:10 +0200 > Daniel Gustafsson wrote: > > I have reviewed your latest patch. > > I can apply this to the master branch and build this successfully, > and the behavior is as expected. > > However, here are some commen

Re: [HACKERS] CLUSTER command progress monitor

> On 12 Sep 2017, at 14:57, Tatsuro Yamada wrote: > > On 2017/09/12 21:20, Tatsuro Yamada wrote: >> On 2017/09/11 23:38, Robert Haas wrote: >>> On Sun, Sep 10, 2017 at 10:36 PM, Tatsuro Yamada >>> wrote: Thanks for the comment. As you know, CLUSTER command uses SEQ SCAN or INDEX

Re: [HACKERS] Fwd: Have a problem with citext

On Fri, Sep 29, 2017 at 6:16 PM, David E. Wheeler wrote: > Are permissions correct in the citext extension? Not to be picky, but couldn't you investigate that a bit before posting here? Off-hand, I see no GRANT or REVOKE statements in any of the citext SQL files, so I'm going to guess that this

Re: [HACKERS] pg_prepared_xact_status

On Mon, Oct 2, 2017 at 9:09 AM, Robert Haas wrote: > On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik > wrote: >> txid_status() also not always be able to return status of transaction (if >> wraparound happen). >> But it is still considered as one of the key features of 10 (transaction >> t

Re: [HACKERS] pg_prepared_xact_status

On Sat, Sep 30, 2017 at 2:10 AM, konstantin knizhnik wrote: > txid_status() also not always be able to return status of transaction (if > wraparound happen). > But it is still considered as one of the key features of 10 (transaction > traceability...). Not by me. It's a feature, though, for su

Re: [HACKERS] Push down more UPDATEs/DELETEs in postgres_fdw

> On 08 Apr 2017, at 16:14, David Steele wrote: > > On 3/22/17 6:20 AM, Etsuro Fujita wrote: >> On 2017/02/22 19:57, Rushabh Lathia wrote: >>> Marked this as Ready for Committer. >> >> I noticed that this item in the CF app was incorrectly marked as >> Committed. This patch isn't committed, so

Re: [HACKERS] postgres_fdw: support parameterized foreign joins

> On 11 Apr 2017, at 10:55, Etsuro Fujita wrote: > > On 2017/04/07 22:54, Arthur Zakirov wrote: >> Marked the patch as "Ready for Commiter". But the patch should be >> commited only after the patch [1]. > > Thanks for reviewing! I'll continue to work on this for PG11. This patch has been marke

Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list

> On 20 Sep 2017, at 01:05, David G. Johnston > wrote: > > On Tue, Sep 19, 2017 at 11:29 AM, Tom Lane > wrote: > ​T​hat​ ​doesn't work today, and this patch doesn't fix it, but it does create > enough confusion that we never would be able to fix it. > > I'd be much h

Re: [HACKERS] parallelize queries containing initplans

> On 15 Sep 2017, at 04:45, Amit Kapila wrote: > > On Thu, Aug 31, 2017 at 11:23 AM, Amit Kapila wrote: >> On Mon, Aug 21, 2017 at 2:40 PM, Amit Kapila wrote: >>> On Mon, Aug 21, 2017 at 1:44 PM, Haribabu Kommi >>> wrote: Thanks for adding more details. It is easy to understan

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

> On 18 Aug 2017, at 13:39, Claudio Freire wrote: > > On Fri, Apr 7, 2017 at 10:51 PM, Claudio Freire > wrote: >> Indeed they do, and that's what motivated this patch. But I'd need >> TB-sized tables to set up something like that. I don't have the >> hardware or time available to do that (vacuu

Re: [HACKERS] 64-bit queryId?

On Sun, Oct 1, 2017 at 3:48 PM, Greg Stark wrote: > Well these kinds of monitoring systems tend to be used by operations > people who are a lot more practical and a lot less worried about > theoretical concerns like that. +1, well said. > In context the point was merely that the default > pg_sta

Re: [HACKERS] Crash on promotion when recovery.conf is renamed

> On 02 Sep 2017, at 14:17, Michael Paquier wrote: > > On Fri, Sep 1, 2017 at 7:17 PM, Thomas Munro > wrote: >> On Sat, Aug 26, 2017 at 7:32 AM, Robert Haas wrote: >>> On Sat, Apr 8, 2017 at 10:05 AM, David Steele wrote: On 3/28/17 1:21 AM, Tsunakawa, Takayuki wrote: > Thanks, marked

Re: [HACKERS] eval_const_expresisions and ScalarArrayOpExpr

I wrote: > This patch no longer applies cleanly on HEAD, so here's a rebased version > (no substantive changes). As before, I think the most useful review task > would be to quantify whether it makes planning noticeably slower. Rebased again (over the arrays-of-domains patch).

Re: [HACKERS] Logging idle checkpoints

On Mon, Oct 2, 2017 at 7:41 AM, Andres Freund wrote: > On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: >> On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: >> > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: >> > I'd be ok with applying this now, or in 10.1 - but I do think we should >>

Re: [HACKERS] Logging idle checkpoints

On 2017-10-02 07:39:18 +0900, Michael Paquier wrote: > On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > > I'd be ok with applying this now, or in 10.1 - but I do think we should > > fix this before 11. If nobody protests I'll push later t

Re: [HACKERS] Logging idle checkpoints

On Mon, Oct 2, 2017 at 7:27 AM, Andres Freund wrote: > On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > I'd be ok with applying this now, or in 10.1 - but I do think we should > fix this before 11. If nobody protests I'll push later today, so we can > get some bf cycles for the very remote case

Re: [HACKERS] Logging idle checkpoints

Hi, On 2017-10-02 00:19:33 +0200, Vik Fearing wrote: > I recently had a sad because I noticed that checkpoint counts were > increasing in pg_stat_bgwriter, but weren't accounted for in my logs > with log_checkpoints enabled. > > After some searching, I found that it was the idle checkpoints that

Re: [HACKERS] Statement-level rollback

> On 15 Sep 2017, at 16:19, Daniel Gustafsson wrote: > >> On 01 Sep 2017, at 13:44, Simon Riggs wrote: >> >> On 14 August 2017 at 23:58, Peter Eisentraut >> wrote: >>> On 2/28/17 02:39, Tsunakawa, Takayuki wrote: The code for stored functions is not written yet, but I'd like your fe

[HACKERS] Logging idle checkpoints

I recently had a sad because I noticed that checkpoint counts were increasing in pg_stat_bgwriter, but weren't accounted for in my logs with log_checkpoints enabled. After some searching, I found that it was the idle checkpoints that weren't being logged. I think this is a missed trick in 6ef2eba

Re: [HACKERS] ANALYZE command progress checker

> On 05 Apr 2017, at 03:17, Masahiko Sawada wrote: > > On Wed, Apr 5, 2017 at 1:49 AM, Robert Haas wrote: >> On Tue, Apr 4, 2017 at 4:57 AM, Amit Langote >> wrote: >>> Hmm, you're right. It could be counted with a separate variable >>> initialized to 0 and incremented every time we decide to a

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 18:01:27 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: > >> So we can leave it out of there. OTOH I'm not a huge fan of security by > >> obscurity. I guess this wouldn't be too bad a case. > > > I'd personally include it, give

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

Andres Freund writes: > On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: >> So we can leave it out of there. OTOH I'm not a huge fan of security by >> obscurity. I guess this wouldn't be too bad a case. > I'd personally include it, given that we already allow and document > ABRT. There's no me

Re: [HACKERS] pgbench: faster version of tpcb-like transaction

> On 27 Aug 2017, at 08:37, Fabien COELHO wrote: > > > About the patch: > > I'm generally in favor of providing more options to pgbench, especially if it > can give optimization ideas to the performance conscious user. > > I think that the name should be "tpcb-like-plfunc": the script does no

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 17:47:52 -0400, Andrew Dunstan wrote: > > > On 10/01/2017 04:48 PM, Andres Freund wrote: > > On 2017-10-01 16:42:44 -0400, Tom Lane wrote: > >> Andrew Dunstan writes: > >>> On 09/30/2017 10:32 PM, Andres Freund wrote: > Heh. I'm inclined to take it out. We could add a --use-t

Re: [HACKERS] PATCH: psql show index with type info

> On 13 Sep 2017, at 01:24, Daniel Gustafsson wrote: > >> On 18 Apr 2017, at 05:13, Amos Bird wrote: >> >> Ah, thanks for the suggestions. I'll revise this patch soon :) > > Have you had a chance to revise the patch to address the review comments such > that the patch can move forward during t

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 10/01/2017 04:48 PM, Andres Freund wrote: > On 2017-10-01 16:42:44 -0400, Tom Lane wrote: >> Andrew Dunstan writes: >>> On 09/30/2017 10:32 PM, Andres Freund wrote: Heh. I'm inclined to take it out. We could add a --use-the-force-luke type parameter, but it doesn't seem worth it. >

Re: [HACKERS] [PATCH] Off-by-one error in logical slot resource retention

> On 15 Sep 2017, at 13:26, Daniel Gustafsson wrote: > >> On 01 Sep 2017, at 14:28, Aleksander Alekseev >> wrote: >> >> The following review has been posted through the commitfest application: >> make installcheck-world: not tested >> Implements feature: not tested >> Spec compliant:

Re: [HACKERS] 200 = 199 + 1?

I wrote: > I experimented a bit with the attached patch, which modifies > eqjoinsel_semi in two ways. First, if the number-of-distinct-values > estimate for the inner rel is just a default rather than having any > real basis, it replaces it with inner_rel->rows, effectively assuming > that the ins

Re: [HACKERS] shm_mq_set_sender() crash

On Thu, Sep 15, 2016 at 06:21:30PM -0400, Robert Haas wrote: > On Thu, Sep 15, 2016 at 5:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> Of course, it's also possible that the ParallelWorkerNumber code is > >> entirely correct and something overwrote the null bytes that were > >> supposed to

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 2017-10-01 16:42:44 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 09/30/2017 10:32 PM, Andres Freund wrote: > >> Heh. I'm inclined to take it out. We could add a --use-the-force-luke > >> type parameter, but it doesn't seem worth it. > > > I agree, but I think we need this discussed

Re: [HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

Andrew Dunstan writes: > On 09/30/2017 10:32 PM, Andres Freund wrote: >> Heh. I'm inclined to take it out. We could add a --use-the-force-luke >> type parameter, but it doesn't seem worth it. > I agree, but I think we need this discussed on -hackers. Does anyone > have an objection to allowing "

[HACKERS] pg_ctl kill support for KILL signal was Re: [COMMITTERS] pgsql: Add test for postmaster crash restarts.

On 09/30/2017 10:32 PM, Andres Freund wrote: > Hi, > > On 2017-09-30 22:28:39 -0400, Andrew Dunstan wrote: But even after fixing that, there unfortunately is: static void set_sig(char *signame) { … #if 0 /* probably should NOT provide SIGKILL */

Re: [HACKERS] 64-bit queryId?

On 1 October 2017 at 16:40, Tom Lane wrote: > Greg Stark writes: >> Indeed. It's simple enough to export stats to prometheus with queryid >> as the key. Then even if the query ages out of the database stats you >> have graphs and derivative metrics going further back. > > I'm not really ready to

Re: [HACKERS] pg_basebackup --progress output for batch execution

Updated patch with documentation of the new option. -- Martín Marquéshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services >From ede201ed96d41d799dc3c83dfab1cdcc03e5ced4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mart=C3=ADn=20Marqu=C3=A9s?= Date:

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Sun, Oct 01, 2017 at 09:56:11AM -0400, Peter Eisentraut wrote: > On 9/30/17 03:01, Noah Misch wrote: > > This PostgreSQL 10 open item is past due for your status update. On the > > worst > > week to be violating open item policies. Kindly send a status update within > > 24 hours, and include

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On Sun, Oct 1, 2017 at 6:27 AM, Peter Eisentraut wrote: > I'm still pondering committing my documentation patch I had posted, and > I've been reviewing your patches to see if there is anything else > documentation-wise that could be added. -1 from me -- I don't think we should tell users about th

Re: [HACKERS] SQL/JSON in PostgreSQL

2017-09-30 1:06 GMT+02:00 Nikita Glukhov : > On 29.09.2017 20:07, Pavel Stehule wrote: > > 2017-09-29 12:15 GMT+02:00 Pavel Stehule : > >> >> 2017-09-29 12:09 GMT+02:00 Nikita Glukhov : >> >>> >>> >>> I have some free time now. Is it last version? >>> >>> Regards >>> >>> Pavel >>> >>> Yes, this is

Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

On 2017-10-01 04:09:19,"Alexander Korotkov" wrote: On Sat, Sep 30, 2017 at 8:18 PM, chenhj wrote: On 2017-09-30 02:17:54，"Alexander Korotkov" wrote: Great. Now code of this patch looks good for me. However, we forgot about documentation. The result is equivalent to replacing the ta

Re: [HACKERS] show precise repos version for dev builds?

Hello, Fabien COELHO writes: I wanted to know which version it was, and "11devel" is kind of imprecise. ... ISTM that extending the version name with the commit id and or date in some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it. configure --with-extra-version=whatever

Re: [HACKERS] 64-bit queryId?

Greg Stark writes: > Indeed. It's simple enough to export stats to prometheus with queryid > as the key. Then even if the query ages out of the database stats you > have graphs and derivative metrics going further back. I'm not really ready to buy into that as a supported use-case, because it imm

Re: [HACKERS] show precise repos version for dev builds?

Fabien COELHO writes: > I wanted to know which version it was, and "11devel" is kind of imprecise. > ... > ISTM that extending the version name with the commit id and or date in > some version output, eg "11devel [2632bcc 2017-09-30 ...]", would do it. configure --with-extra-version=whateveryouw

[HACKERS] Warnings in objectaddress.c

Hello, hackers! I'm building PostgreSQL 10 rc1 sources on Debian wheezy (gcc 4.7). I have those warnings: objectaddress.c: In function ‘get_object_address’: objectaddress.c:1646:10: warning: ‘typeoids[1]’ may be used uninitialized in this function [-Wmaybe-uninitialized] objectaddress.c:1578:8:

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 03:01, Noah Misch wrote: > On Mon, Sep 25, 2017 at 08:26:21AM +, Noah Misch wrote: >> On Tue, Sep 19, 2017 at 07:01:47PM -0700, Peter Geoghegan wrote: >>> On Tue, Sep 19, 2017 at 5:52 PM, Peter Eisentraut >>> wrote: On 9/18/17 18:46, Peter Geoghegan wrote: > As I pointed ou

Re: [HACKERS] Parallel Append implementation

On Sat, Sep 30, 2017 at 9:25 PM, Robert Haas wrote: > On Sat, Sep 30, 2017 at 12:20 AM, Amit Kapila wrote: >> Okay, but the point is whether it will make any difference >> practically. Let us try to see with an example, consider there are >> two children (just taking two for simplicity, we can e

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 15:28, Tom Lane wrote: > This suggests to me that arguing about canonicalization is moot so > far as avoiding reindexing goes: if you change ICU library versions, > you're screwed and will have to jump through all the reindexing hoops, > no matter what we do or don't do. One reason for

Re: [HACKERS] Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/30/17 15:28, Tom Lane wrote: > Now, it may still be worthwhile to argue about whether canonicalization > will help the other component of the problem, which is whether you can > dump and reload CREATE COLLATION commands into a new ICU version and > expect to get more-or-less-the-same behavior

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

Michael Paquier wrote: > On Sun, Oct 1, 2017 at 10:25 AM, Peter Geoghegan wrote: > > On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera > > wrote: > >> Maybe what this means is that we need to do both Dan's initially > >> proposed patch (or something related to it) apart from the fixes already > >>

Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?

On 9/29/17 19:38, Peter Geoghegan wrote: > On Mon, Sep 25, 2017 at 11:40 AM, Peter Eisentraut > wrote: >> Reading over this code again, it is admittedly not quite clear why this >> "canonicalization" is in there right now. I think it had something to >> do with how we built the keyword variants a

Re: [HACKERS] list of credits for release notes

On 9/27/17 14:55, Dave Page wrote: >> Attached is the proposed documentation commit as well as the raw list. > At the very least my name is missing (I contributed the monitoring roles > patch and pg_ls_log/waldir. I have no idea if others are. > > >> Thoughts on the heading? I have considered "

Re: [HACKERS] 64-bit queryId?

On 30 September 2017 at 21:03, Alexander Korotkov wrote: > I heard from customers that they periodically dump contents of > pg_stat_statements and then build statistics over long period of time. If > even they leave default pg_stat_statements.max unchanged, probability of > collision would be si

Re: [HACKERS] why subplan is 10x faster then function?

2017-09-30 23:23 GMT+02:00 Pavel Stehule : > Hi > > I have some strange slow queries based on usage "view" functions > > one function looks like this: > > CREATE OR REPLACE FUNCTION ides_funcs.najdatsplt_cislo_exekuce(mid_najdatsplt > bigint) > RETURNS character varying > LANGUAGE sql > STABLE

Re: [HACKERS] why subplan is 10x faster then function?

2017-10-01 12:45 GMT+02:00 Sokolov Yura : > 1 октября 2017 г. 12:42:14 GMT+03:00, Pavel Stehule < > pavel.steh...@gmail.com> пишет: > >2017-09-30 23:23 GMT+02:00 Pavel Stehule : > > > >> Hi > >> > >> I have some strange slow queries based on usage "view" functions > >> > >> one function looks like

Re: [HACKERS] why subplan is 10x faster then function?

1 октября 2017 г. 12:42:14 GMT+03:00, Pavel Stehule пишет: >2017-09-30 23:23 GMT+02:00 Pavel Stehule : > >> Hi >> >> I have some strange slow queries based on usage "view" functions >> >> one function looks like this: >> >> CREATE OR REPLACE FUNCTION >ides_funcs.najdatsplt_cislo_exekuce(mid_najda

Re: [HACKERS] why subplan is 10x faster then function?

2017-09-30 23:23 GMT+02:00 Pavel Stehule : > Hi > > I have some strange slow queries based on usage "view" functions > > one function looks like this: > > CREATE OR REPLACE FUNCTION ides_funcs.najdatsplt_cislo_exekuce(mid_najdatsplt > bigint) > RETURNS character varying > LANGUAGE sql > STABLE

Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)

On 1 October 2017 at 01:47, Alexander Korotkov wrote: > On Sat, Sep 30, 2017 at 6:12 PM, Shubham Barai > wrote: > >> I have made changes according to your suggestions. Please have a look at >> the updated patch. >> I am also considering your suggestions for my other patches also. But, I >> will

Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple

On Sun, Oct 1, 2017 at 10:25 AM, Peter Geoghegan wrote: > On Thu, Sep 28, 2017 at 1:20 PM, Alvaro Herrera > wrote: >> Maybe what this means is that we need to do both Dan's initially >> proposed patch (or something related to it) apart from the fixes already >> pushed. IOW we need to put back s

[HACKERS] show precise repos version for dev builds?

Hello, I use postgres "11devel" packages kindly distributed on "apt.postgresql.org" and recompiled every few hours. I wanted to know which version it was, and "11devel" is kind of imprecise. Ok, there is a hint in the deb package name: 11~~devel~20170930.2214-1~87.git2632bcc.pgdg16.