Re: [HACKERS] regression test for extended query protocol

On Fri, Aug 5, 2016 at 12:21 AM, Alvaro Herrera wrote: > If somebody had some spare time to devote to this, I would suggest to > implement something in core that can be used to specify a list of > commands to run, and a list of files-to-be-saved-in-bf-log emitted by >

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On 2016/08/02 21:35, Etsuro Fujita wrote: I removed the Relations line. Here is an updated version of the patch. I revised code and comments a bit. Attached is an updated version of the patch. Best regards, Etsuro Fujita explain-for-foreign-join-pushdown-v2.patch Description:

Re: [HACKERS] Detecting skipped data from logical slots (data silently skipped)

On 2016-08-05 00:12:41 -0400, Robert Haas wrote: > > The cause is an optimisation intended to allow the downstream to avoid > > having to do local writes and flushes when the upstream's activity isn't of > > interest to it and doesn't result in replicated rows. When the upstream does > > a bunch

[HACKERS] Refactoring of heapam code.

Working on page compression and some other issues related to access methods, I found out that the code related to heap looks too complicated. Much more complicated, than it should be. Since I anyway got into this area, I want to suggest a set of improvements. There is a number of problems I see

Re: [HACKERS] [sqlsmith] FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)", File: "xlog.c", Line: 10200)

Hello, While the exact cause of the situation is not known yet but we have apparently forgot that pg_stop_backup can be called simultaneously with pg_start_backup. It seems anyway to me that pg_stop_backup should be called before the end of pg_start_backup from their definition and what they do.

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

> "Tom" == Tom Lane writes: Tom> What I did in the patch is to scale the formerly fixed "-1.0" Tom> stadistinct estimate to discount the fraction of nulls we found. This seems quite dubious to me. stadistinct representing only the non-null values seems to me to be

Re: [HACKERS] Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu

On Fri, Aug 5, 2016 at 11:05 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas wrote: >>> What is the reason? We refuse to separate frontend and backend >>> headers in any sort of

Re: [HACKERS] Re: GiST optimizing memmoves in gistplacetopage for fixed-size updates [PoC]

30.07.2016 14:00, Andrew Borodin: Here is BRIN-compatible version of patch. Now function PageIndexTupleOverwrite consumes tuple size as a parameter, this behavior is coherent with PageAddItem. Also, i had to remove asserstion that item has a storage in the loop that adjusts line pointers. It

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Thu, Aug 4, 2016 at 8:14 AM, Aleksander Alekseev wrote: > Thanks everyone for your remarks and comments! > > Here is an improved version of a patch. > > Main changes: > * Patch passes `make installcheck` > * Code is fully commented, also no more TODO's > > I wish I

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Aug 3, 2016 at 5:13 PM, Peter Geoghegan wrote: > On Wed, Aug 3, 2016 at 11:42 AM, Robert Haas wrote: >> I'm not going to say it's bad to be able to do things 2-2.5x faster, >> but linear scalability this ain't - particularly because your 2.58x >>

Re: [HACKERS] Logical Replication WIP

On 5 August 2016 at 16:22, Andres Freund wrote: > On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote: >> as promised here is WIP version of logical replication patch. > > Yay! Yay2 > I'm about to head out for a week of, desperately needed, holidays, but > after that I plan to

[HACKERS] money type overflow checks

The input function of the money type has no overflow checks: => select '12345678901234567890'::money; money - -$13,639,628,150,831,692.72 (1 row) The tests in the regression test file money.sql are bogus because they only test the overflow checks of the

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On 8/5/16 11:58 AM, David Fetter wrote: > For what it's worth, I tend to put the function body last. That's > just my taste, though. Would it be hard to keep the ability to > permute the stuff after > > CREATE FUNCTION (args) > RETURNS [SETOF] type > > as we have it now? I don't think

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

On Thu, Aug 4, 2016 at 12:14 AM, Noah Misch wrote: > On Wed, Aug 03, 2016 at 05:52:44PM -0400, Tom Lane wrote: >> I wrote: >> > I'm thinking there are two distinct bugs here. >> >> Actually, make that three bugs. I was so focused on the crashing >> that I failed to notice that

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On Fri, Aug 05, 2016 at 10:14:21AM -0400, Peter Eisentraut wrote: > On 7/3/16 11:41 AM, Tom Lane wrote: > > I can see the reasoning for > > allowing COMMENT in a table column definition, but the argument for > > allowing it in simpler CREATEs seems tissue-thin: > > > > CREATE FUNCTION

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Fri, Aug 5, 2016 at 3:25 AM, Tsunakawa, Takayuki wrote: >> From: Tom Lane [mailto:t...@sss.pgh.pa.us] >> Yeah, I think I agree. It would be bad to disable it by default on Unix, >> because ps(1) is a very standard tool there, but the same argument doesn't >>

[HACKERS] Notice lock waits

One time too many, I ran some minor change using psql on a production server and was wondering why it was taking so much longer than it did on the test server. Only to discover, after messing around with opening new windows and running queries against pg_stat_activity and pg_locks and so on, that

Re: [HACKERS] money type overflow checks

Peter Eisentraut writes: > The input function of the money type has no overflow checks: Ugh. > (Is checking for < 0 a valid overflow check? No, I don't think it's sufficient after a multiplication by 10. That would be enough to shift some bits clear out of

[HACKERS] truncate trigger for foreign data wrappers

Hello I recently hit a road blocker when I tried to create a truncate trigger on a foreign table. trigger.c::CreateTrigger() function has explicit check to block truncate trigger on foreign tables. However, trigger.c::ExecuteTruncate() does not seem to have any problems issuing before/after

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

På fredag 05. august 2016 kl. 01:01:06, skrev Tom Lane >: I wrote: > Looking around, there are a couple of places outside commands/analyze.c > that are making the same mistake, so this patch isn't complete, but it > illustrates what needs to be

Re: [HACKERS] Hash Indexes

On Thu, Aug 4, 2016 at 8:02 PM, Mithun Cy wrote: > I did some basic testing of same. In that I found one issue with cursor. > Thanks for the testing. The reason for failure was that the patch didn't take into account the fact that for scrolling cursors, scan can

Re: [HACKERS] [RFC] Change the default of update_process_title to off

> From: Tom Lane [mailto:t...@sss.pgh.pa.us] > Yeah, I think I agree. It would be bad to disable it by default on Unix, > because ps(1) is a very standard tool there, but the same argument doesn't > hold for Windows. It seems that we could reach a consensus. The patch is attached. I'll add

Re: [HACKERS] Declarative partitioning

The lists for list partitioned tables are stored as they are specified by the user. While searching for a partition to route tuple to, we compare it with every list value of every partition. We might do something better similar to what's been done to range partitions. The list of values for a

Re: [HACKERS] Refactoring of heapam code.

On 5 August 2016 at 08:54, Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got

Re: [HACKERS] PostgreSQL 10 Roadmaps

On 5 August 2016 at 04:40, Etsuro Fujita wrote: > On 2016/08/02 23:54, Simon Riggs wrote: >> >> https://wiki.postgresql.org/wiki/PostgreSQL10_Roadmap > > > Thank you for creating the wiki page! > > I added a link to the NTT roadmap page on the links page. We hope

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

> "Andrew" == Andrew Gierth writes: > "Tom" == Tom Lane writes: Tom> What I did in the patch is to scale the formerly fixed "-1.0" Tom> stadistinct estimate to discount the fraction of nulls we found. Andrew> This seems quite dubious

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On 5 August 2016 at 12:25, Tsunakawa, Takayuki wrote: > It seems that we could reach a consensus. The patch is attached. I'll add > this to the next CommitFest. + The default is off on Windows + because the overhead is significant, and on on

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee > wrote: > > > > > > I don't see why it is hard. Trying to find the index entry for the old > > update row seems odd, and updating an index

Re: [HACKERS] truncate trigger for foreign data wrappers

On Fri, Aug 5, 2016 at 10:39 AM, Andres Freund wrote: > On 2016-08-05 10:33:49 -0400, Tom Lane wrote: >> Murat Tuncer writes: >> > I recently hit a road blocker when I tried to create a truncate trigger on >> > a foreign table.

Re: [HACKERS] truncate trigger for foreign data wrappers

On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote: > On 2016-08-05 13:32:18 -0400, Robert Haas wrote: >> I think if we're going to add support utility commands on foreign >> tables, we ought to think about all of the different utility commands >> that someone might want and

Re: [HACKERS] multivariate statistics (v19)

On 08/05/2016 06:24 AM, Michael Paquier wrote: On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra wrote: Attached is v19 of the "multivariate stats" patch series - essentially v18 rebased on top of current master. Aside from a few bug fixes, the main improvement is

Re: [HACKERS] Re: [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

Robert Haas writes: > Action within 72 hours now seems inadequate; we are scheduled to wrap > rc1 on Monday. We need someone to either fix these bugs very very > soon, or decide to ship beta4 instead of rc1 (uggh), or decide it's OK > to ship rc1 with these known defects,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 2:26 PM, Pavan Deolasee wrote: > On Fri, Aug 5, 2016 at 8:55 PM, Claudio Freire > wrote: >> >> On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee >> wrote: >> > >> > >> > I don't see why it is hard.

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > But doing the WARM chain backtracking and checking for previous > versions with appropriate keys should be enough to support this use > case too, it just needs to be well optimized to avoid seriously > impacting performance on the

Re: [HACKERS] Refactoring of heapam code.

Anastasia Lubennikova wrote: > Working on page compression and some other issues related to > access methods, I found out that the code related to heap > looks too complicated. Much more complicated, than it should be. > Since I anyway got into this area, I want to suggest a set of improvements.

Re: [HACKERS] truncate trigger for foreign data wrappers

On 2016-08-05 13:32:18 -0400, Robert Haas wrote: > I think if we're going to add support utility commands on foreign > tables, we ought to think about all of the different utility commands > that someone might want and what exactly we want the behavior to be. > For example, consider CLUSTER or

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote: >> On 8/2/16 12:51 PM, Bruce Momjian wrote: >> > Yes, that's a strong argument for using a space. I have adjusted the >> > patch to use spaces in all

Re: [HACKERS] truncate trigger for foreign data wrappers

On 2016-08-05 14:05:02 -0400, Robert Haas wrote: > On Fri, Aug 5, 2016 at 2:04 PM, Andres Freund wrote: > > On 2016-08-05 13:32:18 -0400, Robert Haas wrote: > >> I think if we're going to add support utility commands on foreign > >> tables, we ought to think about all of the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > > But doing the WARM chain backtracking and checking for previous > > versions with appropriate keys should be enough to support this use > > case too, it

Re: [HACKERS] pg_replication_origin_xact_reset() and its argument variables

On Tue, Aug 2, 2016 at 2:59 AM, Fujii Masao wrote: > On Tue, Aug 2, 2016 at 2:48 AM, Andres Freund wrote: >> Hi Fujii, >> >> On 2016-07-28 16:44:37 +0900, Fujii Masao wrote: >>> On Sat, Jul 2, 2016 at 7:01 AM, Tom Lane wrote: >>> >

Re: [HACKERS] Hash index with larger hashes

On Fri, Aug 5, 2016 at 10:39 AM, Kenneth Marshall wrote: > I have been following the recent discussions on increasing the > size of the hash function used in Postgres and the work to > provide WAL and performance improvements for hash indexes. > I know it was mentioned when we

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

> "Tom" == Tom Lane writes: Tom> Also, the way that the value is calculated in the Tom> samples-not-all-distinct case corresponds to the way I have it in Tom> the patch. Ahh, gotcha. You're referring to this: /* * If we estimated the number of

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat wrote: > The lists for list partitioned tables are stored as they are specified by > the user. While searching for a partition to route tuple to, we compare it > with every list value of every partition. We might do

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote: > On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat > wrote: > > The lists for list partitioned tables are stored as they are specified by > > the user. While searching for a partition to

Re: [HACKERS] Declarative partitioning

> > > > > Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a > > list partitioned tables. I am suggesting that we arrange them as > > ('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row > (either > > for comparison or for inserting) has value 'c', we will

Re: [HACKERS] Refactoring of heapam code.

On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: > They can be logically separated into three categories: > "primary storage" - r, S, t, v. They store data and visibility information. > The only implementation is heapam.c > "secondary index" - i. They

Re: [HACKERS] regression test for extended query protocol

On Tue, Aug 2, 2016 at 10:33 PM, Tatsuo Ishii wrote: > In my understanding, we don't have any regression test for protocol > level prepared query (we do have SQL level prepared query tests, > though). Shouldn't we add those tests to the regression test suites? A few years

Re: [HACKERS] Declarative partitioning

On Fri, Aug 5, 2016 at 8:10 AM, Ashutosh Bapat wrote: > On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote: >> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat >> wrote: >> > The lists for list partitioned

Re: [HACKERS] handling unconvertible error messages

On Thu, 04 Aug 2016 14:25:52 -0400 Tom Lane wrote: > Victor Wagner writes: > > Really, if this response is sent after backend has been forked, > > problem probably can be easily fixed better way - StartupMessage > > contain information about desired

Re: [HACKERS] Cache Hash Index meta page.

On Thu, Aug 4, 2016 at 3:36 AM, Tom Lane wrote: > Jeff Janes writes: >> On Fri, Jul 22, 2016 at 3:02 AM, Mithun Cy >> wrote: >>> I have created a patch to cache the meta page of Hash index in >>> backend-private memory. This

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On Tue, Jul 26, 2016 at 11:20 PM, Etsuro Fujita wrote: > I noticed that currently the core doesn't show any information on the target > relations involved in a foreign/custom join in EXPLAIN, by itself. I think that's a feature, not a bug. > postgres_fdw shows the

Re: [HACKERS] Refactoring of heapam code.

05.08.2016 16:30, Kevin Grittner: On Fri, Aug 5, 2016 at 2:54 AM, Anastasia Lubennikova wrote: They can be logically separated into three categories: "primary storage" - r, S, t, v. They store data and visibility information. The only implementation is heapam.c

Re: [HACKERS] [sqlsmith] FailedAssertion("!(k == indices_count)", File: "tsvector_op.c", Line: 511)

Thomas Munro writes: > The assertion in tsvector_delete_by_indices fails because its counting > algorithm doesn't expect indices_to_delete to contain multiple > references to the same index. Maybe that could be fixed by > uniquifying in tsvector_delete_arr before

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On Fri, Aug 5, 2016 at 02:07:18PM -0400, Robert Haas wrote: > On Fri, Aug 5, 2016 at 11:06 AM, Bruce Momjian wrote: > > On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote: > >> On 8/2/16 12:51 PM, Bruce Momjian wrote: > >> > Yes, that's a strong argument for using

Re: [HACKERS] Notice lock waits

Jeff Janes writes: > I have it PGC_SUSET because it does send some tiny amount of > information about the blocking process (the PID) to the blocked > process. That is probably too paranoid, because the PID can be seen > by anyone in the pg_locks table anyway. Why not just

Re: [HACKERS] Notice lock waits

On 05/08/2016 19:00, Jeff Janes wrote: > One time too many, I ran some minor change using psql on a production > server and was wondering why it was taking so much longer than it did > on the test server. Only to discover, after messing around with > opening new windows and running queries

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote: > On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: > > On Fri, Aug  5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: > > But doing the WARM chain backtracking and checking for previous > >

Re: [HACKERS] Column COMMENTs in CREATE TABLE?

On 7/3/16 11:41 AM, Tom Lane wrote: > I can see the reasoning for > allowing COMMENT in a table column definition, but the argument for > allowing it in simpler CREATEs seems tissue-thin: > > CREATE FUNCTION foo(int) RETURNS ... ; > COMMENT ON FUNCTION foo(int) IS 'blah'; > > vs > >

Re: [HACKERS] truncate trigger for foreign data wrappers

Murat Tuncer writes: > I recently hit a road blocker when I tried to create a truncate trigger on > a foreign table. trigger.c::CreateTrigger() function has explicit check to > block truncate trigger on foreign tables. That's good, because we don't implement TRUNCATE on

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Fri, Aug 5, 2016 at 01:12:39PM +0200, David Rowley wrote: > On 5 August 2016 at 12:25, Tsunakawa, Takayuki > wrote: > > It seems that we could reach a consensus. The patch is attached. I'll add > > this to the next CommitFest. > > > + The default

Re: [HACKERS] Slowness of extended protocol

On Tue, Aug 2, 2016 at 2:00 PM, Shay Rojansky wrote: >> Shay, why don't you use a profiler? Seriously. >> I'm afraid "iterate the per-message loop in PostgresMain five times not >> once" /"just discussing what may or may not be a problem..." is just >> hand-waving. >> >> Come on,

Re: [HACKERS] regression test for extended query protocol

Robert Haas writes: > I think it would be an interesting project for someone to try to > figure out how to make 'make check-extended-query-protocol' or similar > work. Seems like it would not be that hard to put some kind of option in psql to issue queries with

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:57:19AM +0530, Pavan Deolasee wrote: > Hmm. That seems like a real problem. The only way to address that is to ensure > that for a given WARM chain and given index key, there must exists only a > single index entry. There can and will be multiple entries if the index key

Re: [HACKERS] Slowness of extended protocol

On Wed, Aug 3, 2016 at 7:35 PM, Bruce Momjian wrote: > On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote: >> Bruce Momjian writes: >> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote: >> >> In hindsight it seems clear that what a lot of apps

Re: [HACKERS] Reviewing freeze map code

On Thu, Aug 4, 2016 at 3:24 AM, Andres Freund wrote: > Hi, > > On 2016-08-02 10:55:18 -0400, Noah Misch wrote: >> [Action required within 72 hours. This is a generic notification.] >> >> The above-described topic is currently a PostgreSQL 9.6 open item. Andres, >> since you

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

Andrew Gierth writes: > Hm. I am wrong about this, since it's the fact that consumers are taking > stanullfrac into account that makes the value wrong in the first place. Also, the way that the value is calculated in the samples-not-all-distinct case corresponds to

Re: [HACKERS] Notice lock waits

On Fri, Aug 5, 2016 at 12:17 PM, Tom Lane wrote: > Jeff Janes writes: >> I have it PGC_SUSET because it does send some tiny amount of >> information about the blocking process (the PID) to the blocked >> process. That is probably too paranoid, because

Re: [HACKERS] truncate trigger for foreign data wrappers

Andres Freund writes: > On 2016-08-05 16:35:02 -0400, Tom Lane wrote: >> In particular, it seems to me that rather than implement just this, >> we really ought to provide an API that lets FDWs actually implement >> TRUNCATE if they feel like it. Having the trigger and not

Re: [HACKERS] Bogus ANALYZE results for an otherwise-unique column with many nulls

Andrew Gierth writes: > Objection withdrawn. OK, thanks. What shall we do about Andreas' request to back-patch this? I'm personally willing to do it, but there is the old bugaboo of "maybe it will destabilize a plan that someone is happy with".

Re: [HACKERS] truncate trigger for foreign data wrappers

On 2016-08-05 16:44:20 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-05 16:35:02 -0400, Tom Lane wrote: > >> In particular, it seems to me that rather than implement just this, > >> we really ought to provide an API that lets FDWs actually implement > >>

[HACKERS] Add hint for people who place EXECUTE USING arguments in parentheses (in plpgsql)

Basically, diff --git a/src/backend/parser/parse_param.c b/src/backend/parser/parse_param.c index b402843..97064fc 100644 --- a/src/backend/parser/parse_param.c +++ b/src/backend/parser/parse_param.c @@ -108,6 +108,9 @@ fixed_paramref_hook(ParseState *pstate, ParamRef *pref) ereport(ERROR,

Re: [HACKERS] truncate trigger for foreign data wrappers

Andres Freund writes: > On 2016-08-05 14:05:02 -0400, Robert Haas wrote: >> I agree, but I still think it's weird if foreign tables support >> TRUNCATE itself not but triggers on TRUNCATE. > You mean the other way round? To me this seems very comparable to > INSTEAD

Re: [HACKERS] truncate trigger for foreign data wrappers

On 2016-08-05 16:35:02 -0400, Tom Lane wrote: > In particular, it seems to me that rather than implement just this, > we really ought to provide an API that lets FDWs actually implement > TRUNCATE if they feel like it. Having the trigger and not TRUNCATE > capability itself just screams "half

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Fri, Aug 5, 2016 at 9:06 AM, Robert Haas wrote: > To some extent, sure, absolutely. But it's our job as developers to > try to foresee and minimize those cases. When Noah was at > EnterpriseDB a few years ago and we were talking about parallel > internal sort, Noah

Re: [HACKERS] pg_ctl promote wait

On 8/5/16 12:14 AM, Michael Paquier wrote: > In do_stop, this patches makes the wait happen for a maximum of > wait_seconds * 2, once when getting the control file information, and > once when waiting for the server to shut down. That's not how I read it. get_controlfile() will decrease the

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote: > So to summarize again: > > o chains start out as HOT > o they become WARM when some indexes change and others don't > o for multiple index changes, we have to check all indexes >for key/ctid matches > o for single index

Re: [HACKERS] New version numbering practices

Peter Eisentraut writes: > One hiccup I found is that server_version_num is not sent to clients. > Instead, libpq assembles the numeric version number itself from the > string version, and it will fail if it sees only one number (e.g., > 10devel). It will then

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 9:21 PM, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: >> On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: >>> > This does create more HOT chains where the root ctid cannot be removed,

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:21:49PM -0300, Claudio Freire wrote: > On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: > > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: > >> > This does create more HOT chains where the root ctid cannot be removed, > >> > but it

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 4:26 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 11:30:26PM +0530, Pavan Deolasee wrote: >> On Fri, Aug 5, 2016 at 11:26 PM, Bruce Momjian wrote: >> >> On Fri, Aug 5, 2016 at 02:43:37PM -0300, Claudio Freire wrote: >> >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 09:02:39PM -0400, Bruce Momjian wrote: > Yes, it seems we either find the entry fast and avoid the index > addition, or don't find it quickly and use a non-HOT, non-WARM update. > The problem is that you have to do this for multiple indexes, and if you > quickly find you

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 03:26:15PM -0400, Bruce Momjian wrote: > > I just don't know how would you do that without delaying/not-doing HOT chain > > prune. As soon as root and intermediate HOT tuples are gone, all > > information is > > lost. You may delay that, but that will defeat the whole

Re: [HACKERS] multivariate statistics (v19)

On Sat, Aug 6, 2016 at 2:38 AM, Tomas Vondra wrote: > On 08/05/2016 06:24 AM, Michael Paquier wrote: >> >> On Wed, Aug 3, 2016 at 10:58 AM, Tomas Vondra >> wrote: >>> >>> Attached is v19 of the "multivariate stats" patch series -

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 9:07 PM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: >> > This does create more HOT chains where the root ctid cannot be removed, >> > but it does avoid the index key/ctid check because any entry in the HOT >> >

Re: [HACKERS] Slowness of extended protocol

> > > I really don't get what's problematic with posting a message on a mailing > > list about a potential performance issue, to try to get people's > reactions, > > without diving into profiling right away. I'm not a PostgreSQL developer, > > have other urgent things to do and don't even spend

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 07:51:05PM -0300, Claudio Freire wrote: > > This does create more HOT chains where the root ctid cannot be removed, > > but it does avoid the index key/ctid check because any entry in the HOT > > chain has identical keys. What this would not handle is when an entire > >

Re: [HACKERS] System load consideration before spawning parallel workers

On 8/1/16 1:08 AM, Haribabu Kommi wrote: There are some utilities and functions that are available to calculate the current system load, based on the available resources and system load, the module can allow the number of parallel workers that can start. In my observation, adding this

Re: [HACKERS] Surprising behaviour of \set AUTOCOMMIT ON

On Thu, Aug 4, 2016 at 7:46 PM, Pavel Stehule wrote: > 2016-08-04 15:37 GMT+02:00 Amit Kapila : >> >> > I dislike automatic commit or rollback here. >> > >> >> What problem you see with it, if we do so and may be mention the same >> in docs as

Re: [HACKERS] "Some tests to cover hash_index"

On Thu, Aug 4, 2016 at 7:24 PM, Mithun Cy wrote: > I am attaching the patch to improve some coverage of hash index code [1]. > I have added some basic tests, which mainly covers overflow pages. It took > 2 sec extra time in my machine in parallel schedule. > > > > >

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Sat, Aug 6, 2016 at 8:34 AM, Bruce Momjian wrote: > On Fri, Aug 5, 2016 at 09:40:35PM -0400, Bruce Momjian wrote: > > So to summarize again: > > > > o chains start out as HOT > > o they become WARM when some indexes change and others don't > > o for multiple index

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On 8/2/16 12:51 PM, Bruce Momjian wrote: > Yes, that's a strong argument for using a space. I have adjusted the > patch to use spaces in all reasonable places. Patch attached, which I > have gzipped because it was 133 KB. (Ah, see what I did there?) :-) > > I am thinking of leaving the 9.6

Re: [HACKERS] pg_size_pretty, SHOW, and spaces

On Fri, Aug 5, 2016 at 10:57:35AM -0400, Peter Eisentraut wrote: > On 8/2/16 12:51 PM, Bruce Momjian wrote: > > Yes, that's a strong argument for using a space. I have adjusted the > > patch to use spaces in all reasonable places. Patch attached, which I > > have gzipped because it was 133 KB.

Re: [HACKERS] Logical Replication WIP

On 2016-08-05 17:00:13 +0200, Petr Jelinek wrote: > as promised here is WIP version of logical replication patch. Yay! I'm about to head out for a week of, desperately needed, holidays, but after that I plan to spend a fair amount of time helping to review etc. this. -- Sent via pgsql-hackers

Re: [HACKERS] Heap WARM Tuples - Design Draft

On Fri, Aug 5, 2016 at 1:27 AM, Pavan Deolasee wrote: > > > On Fri, Aug 5, 2016 at 8:23 AM, Claudio Freire > wrote: >> >> On Thu, Aug 4, 2016 at 11:15 PM, Bruce Momjian wrote: >> >> > >> > OK, that's a lot of text, and I am

Re: [HACKERS] truncate trigger for foreign data wrappers

On 2016-08-05 10:33:49 -0400, Tom Lane wrote: > Murat Tuncer writes: > > I recently hit a road blocker when I tried to create a truncate trigger on > > a foreign table. trigger.c::CreateTrigger() function has explicit check to > > block truncate trigger on foreign tables. >

[HACKERS] Hash index with larger hashes

Hello Developers, I have been following the recent discussions on increasing the size of the hash function used in Postgres and the work to provide WAL and performance improvements for hash indexes. I know it was mentioned when we moved to the new hashing functions, but the existing functions do

Re: [HACKERS] Re: [COMMITTERS] pgsql: Prevent "snapshot too old" from trying to return pruned TOAST tu

Robert Haas writes: > On Thu, Aug 4, 2016 at 10:58 PM, Robert Haas wrote: >> What is the reason? We refuse to separate frontend and backend >> headers in any sort of principled way? > That was poorly phrased. I'll try again: I can't see any reason

Re: [HACKERS] handling unconvertible error messages

On 8/4/16 9:42 AM, Tom Lane wrote: > I'm inclined to think that we should reset the message locale > to C as soon as we've forked away from the postmaster, and leave it > that way until we've absorbed settings from the startup packet. > Sending messages of this sort in English isn't great, but

Re: [HACKERS] handling unconvertible error messages

On 8/4/16 2:45 AM, Victor Wagner wrote: > 4. At the session startup try to reinitializie LC_MESSAGES locale > category with the combination > of the server (or better client-send) language and region and > client-supplied encoding, and if this failed, use untranslated error > message. Obvoisly,

Re: [HACKERS] improved DefElem list processing

On 8/4/16 2:21 PM, Tom Lane wrote: > Forgot to mention: seems like you should have added a location > argument to makeDefElem. I was hesitating to do that lest it break extensions or something, but I guess we break bigger things than that all the time. I'll change it. -- Peter Eisentraut

  1   2   >