Re: [HACKERS] Remove duplicate setting in test/recovery/Makefile

On Wed, Nov 8, 2017 at 10:38 AM, Masahiko Sawada wrote: > Hi, > > I found that EXTRA_INSTALL is doubly set at both top and bottom of the > src/test/recovery/Makefile. Is it necessary? > > Attached patch fixes this. Indeed, there is some bad overlap between d851bef and 1148e22a. Better to CC Simon

[HACKERS] Remove duplicate setting in test/recovery/Makefile

Hi, I found that EXTRA_INSTALL is doubly set at both top and bottom of the src/test/recovery/Makefile. Is it necessary? Attached patch fixes this. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center remove_duplicate_setting.patch Description:

Re: [HACKERS] Remove secondary checkpoint

On Wed, Nov 8, 2017 at 2:23 AM, Simon Riggs wrote: > On 31 October 2017 at 12:01, Michael Paquier > wrote: >> While the mention about a manual checkpoint happening after a timed >> one will cause a full range of WAL segments to be recycled, it is not >> actually true that segments of the prior's

Re: [HACKERS] Remove secondary checkpoint

On 31 October 2017 at 12:01, Michael Paquier wrote: > On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote: >> On 30 October 2017 at 18:58, Simon Riggs wrote: >>> On 30 October 2017 at 15:22, Simon Riggs wrote: >>> > You forgot to update this formula in xlog.c: > distance = (2.0 + Che

Re: [HACKERS] Remove inbound links to sql-createuser

David, * Stephen Frost (sfr...@snowman.net) wrote: > * David G. Johnston (david.g.johns...@gmail.com) wrote: > > Since CREATE USER is officially an alias for CREATE ROLE other parts of the > > documentation should point to CREATE ROLE, not CREATE USER. Most do but I > > noticed when looking at CR

Re: [HACKERS] Remove secondary checkpoint

On Tue, Oct 31, 2017 at 2:00 PM, Simon Riggs wrote: > On 30 October 2017 at 18:58, Simon Riggs wrote: >> On 30 October 2017 at 15:22, Simon Riggs wrote: >> You forgot to update this formula in xlog.c: distance = (2.0 + CheckPointCompletionTarget) * CheckPointDistanceEstimate;

Re: [HACKERS] Remove secondary checkpoint

On 30 October 2017 at 18:58, Simon Riggs wrote: > On 30 October 2017 at 15:22, Simon Riggs wrote: > >>> You forgot to update this formula in xlog.c: >>> distance = (2.0 + CheckPointCompletionTarget) * >>> CheckPointDistanceEstimate; >>> /* add 10% for good measure. */ >>> distance *=

Re: [HACKERS] Remove inbound links to sql-createuser

David, * David G. Johnston (david.g.johns...@gmail.com) wrote: > Since CREATE USER is officially an alias for CREATE ROLE other parts of the > documentation should point to CREATE ROLE, not CREATE USER. Most do but I > noticed when looking at CREATE DATABASE that it did not. Further searching >

[HACKERS] Remove inbound links to sql-createuser

Since CREATE USER is officially an alias for CREATE ROLE other parts of the documentation should point to CREATE ROLE, not CREATE USER. Most do but I noticed when looking at CREATE DATABASE that it did not. Further searching turned up the usage in client-auth.sgml. That one is questionable since

Re: [HACKERS] Remove secondary checkpoint

On 30 October 2017 at 15:22, Simon Riggs wrote: >> You forgot to update this formula in xlog.c: >> distance = (2.0 + CheckPointCompletionTarget) * >> CheckPointDistanceEstimate; >> /* add 10% for good measure. */ >> distance *= 1.10; >> You can guess easily where the mistake is. > >

Re: [HACKERS] Remove secondary checkpoint

On 2017-10-30 10:10:19 -0400, Tom Lane wrote: > Robert Haas writes: > > I was mostly just thinking out loud, listing another option rather > > than advocating for it. > > FWIW, I just wanted the question to be debated and resolved properly. > > After rereading the thread Andres pointed to, I tho

Re: [HACKERS] Remove secondary checkpoint

On 30 October 2017 at 15:31, Michael Paquier wrote: > On Mon, Oct 30, 2017 at 2:22 PM, Simon Riggs wrote: >> On 25 October 2017 at 00:17, Michael Paquier >> wrote: >>> -* Delete old log files (those no longer needed even for previous >>> -* checkpoint or the standbys in XLOG streaming).

Re: [HACKERS] Remove secondary checkpoint

On Mon, Oct 30, 2017 at 2:22 PM, Simon Riggs wrote: > On 25 October 2017 at 00:17, Michael Paquier > wrote: >> -* Delete old log files (those no longer needed even for previous >> -* checkpoint or the standbys in XLOG streaming). >> +* Delete old log files and recycle them >> */

Re: [HACKERS] Remove secondary checkpoint

On 25 October 2017 at 00:17, Michael Paquier wrote: > On Mon, Oct 23, 2017 at 11:20 PM, Simon Riggs wrote: >> Remove the code that maintained two checkpoint's WAL files and all >> associated stuff. >> >> Try to avoid breaking anything else >> >> This >> * reduces disk space requirements on master

Re: [HACKERS] Remove secondary checkpoint

Robert Haas writes: > I was mostly just thinking out loud, listing another option rather > than advocating for it. FWIW, I just wanted the question to be debated and resolved properly. After rereading the thread Andres pointed to, I thought of a hazard that I think Andres alluded to, but didn't

Re: [HACKERS] Remove secondary checkpoint

On Mon, Oct 30, 2017 at 7:04 PM, Alvaro Herrera wrote: >> A sort of middle way would be to keep the secondary checkpoint around >> but never try to replay from that point, or only if a specific flag is >> provided. > > Why do you want to keep the secondary checkpoint? If there is no way to > auto

Re: [HACKERS] Remove secondary checkpoint

On Mon, Oct 30, 2017 at 7:04 PM, Alvaro Herrera wrote: > Robert Haas wrote: >> On Tue, Oct 24, 2017 at 7:25 PM, Andres Freund wrote: >> > I think it does the contrary. The current mechanism is, in my opinion, >> > downright dangerous: >> > https://www.postgresql.org/message-id/20160201235854.go8.

Re: [HACKERS] Remove secondary checkpoint

Robert Haas wrote: > On Tue, Oct 24, 2017 at 7:25 PM, Andres Freund wrote: > > I think it does the contrary. The current mechanism is, in my opinion, > > downright dangerous: > > https://www.postgresql.org/message-id/20160201235854.go8...@awork2.anarazel.de > > A sort of middle way would be to ke

Re: [HACKERS] Remove secondary checkpoint

On Tue, Oct 24, 2017 at 7:25 PM, Andres Freund wrote: > I think it does the contrary. The current mechanism is, in my opinion, > downright dangerous: > https://www.postgresql.org/message-id/20160201235854.go8...@awork2.anarazel.de A sort of middle way would be to keep the secondary checkpoint aro

Re: [HACKERS] Remove secondary checkpoint

From: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org] > Tsunakawa, Takayuki wrote: > > > (Although unrelated to this, I've also been wondering why PostgreSQL > > flushes WAL to disk when writing a page in the shared buffer, because > > PostgreSQL doesn't use WAL for undo.) > > The reason is that

Re: [HACKERS] Remove secondary checkpoint

Tsunakawa, Takayuki wrote: > (Although unrelated to this, I've also been wondering why PostgreSQL > flushes WAL to disk when writing a page in the shared buffer, because > PostgreSQL doesn't use WAL for undo.) The reason is that if the system crashes after writing the data page to disk, but befor

Re: [HACKERS] Remove secondary checkpoint

On Tue, Oct 24, 2017 at 7:24 PM, Tsunakawa, Takayuki wrote: > (3) > Should we change the default value of max_wal_size from 1 GB to a smaller > size? I vote for "no" for performance. The default has just changed in v10, so changing it again could be confusing, so I agree with your position. --

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Simon Riggs > This > * reduces disk space requirements on master > * removes a minor bug in fast failover > * simplifies code I welcome this patch. I was wondering why PostgreSQL retains the previo

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier > On Tue, Oct 24, 2017 at 5:58 PM, Tsunakawa, Takayuki > wrote: > > If the latest checkpoint record is unreadable (the WAL > segment/block/record is corrupt?), recovery from the prev

Re: [HACKERS] Remove secondary checkpoint

On Tue, Oct 24, 2017 at 5:58 PM, Tsunakawa, Takayuki wrote: > If the latest checkpoint record is unreadable (the WAL segment/block/record > is corrupt?), recovery from the previous checkpoint would also stop at the > latest checkpoint. And we don't need to replay the WAL records between the >

Re: [HACKERS] Remove secondary checkpoint

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Doesn't it also make crash recovery less robust? The whole point > of that mechanism is to be able to cope if the latest checkpoint > record is unreadable. If the latest checkpoint recor

Re: [HACKERS] Remove secondary checkpoint

On Mon, Oct 23, 2017 at 11:20 PM, Simon Riggs wrote: > Remove the code that maintained two checkpoint's WAL files and all > associated stuff. > > Try to avoid breaking anything else > > This > * reduces disk space requirements on master > * removes a minor bug in fast failover > * simplifies code

Re: [HACKERS] Remove secondary checkpoint

On 24 October 2017 at 09:50, Tom Lane wrote: > Simon Riggs writes: >> Remove the code that maintained two checkpoint's WAL files and all >> associated stuff. > >> Try to avoid breaking anything else > >> This >> * reduces disk space requirements on master >> * removes a minor bug in fast failover

Re: [HACKERS] Remove secondary checkpoint

On 2017-10-24 09:50:12 -0400, Tom Lane wrote: > Simon Riggs writes: > > Remove the code that maintained two checkpoint's WAL files and all > > associated stuff. > > > Try to avoid breaking anything else > > > This > > * reduces disk space requirements on master > > * removes a minor bug in fast

Re: [HACKERS] Remove secondary checkpoint

Simon Riggs writes: > Remove the code that maintained two checkpoint's WAL files and all > associated stuff. > Try to avoid breaking anything else > This > * reduces disk space requirements on master > * removes a minor bug in fast failover > * simplifies code Doesn't it also make crash recover

[HACKERS] Remove secondary checkpoint

Remove the code that maintained two checkpoint's WAL files and all associated stuff. Try to avoid breaking anything else This * reduces disk space requirements on master * removes a minor bug in fast failover * simplifies code -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] Remove 1MB size limit in tsvector

On 09/11/2017 01:54 PM, Robert Haas wrote: > On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev > wrote: >> Moreover, RUM index >> stores positions + lexemes, so it doesn't need tsvectors for ranked >> search. As a result, tsvector becomes a storage for >> building indexes (indexable type), not s

Re: [HACKERS] Remove 1MB size limit in tsvector

On Mon, Sep 11, 2017 at 5:33 AM, Ildus Kurbangaliev wrote: > Moreover, RUM index > stores positions + lexemes, so it doesn't need tsvectors for ranked > search. As a result, tsvector becomes a storage for > building indexes (indexable type), not something that should be used at > runtime. And the

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, 7 Sep 2017 23:08:14 +0200 Tomas Vondra wrote: > Hi, > > On 08/17/2017 12:23 PM, Ildus Kurbangaliev wrote: > > In my benchmarks when database fits into buffers (so it's > > measurement of the time required for the tsvectors conversion) it > > gives me these results: > > > > Without conve

Re: [HACKERS] Remove 1MB size limit in tsvector

Hi, On 08/17/2017 12:23 PM, Ildus Kurbangaliev wrote: > In my benchmarks when database fits into buffers (so it's measurement of > the time required for the tsvectors conversion) it gives me these > results: > > Without conversion: > > $ ./tsbench2 -database test1 -bench_time 300 > 2017/08/17 12

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, 10 Aug 2017 18:06:17 +0300 Alexander Korotkov wrote: > On Wed, Aug 9, 2017 at 7:38 PM, Robert Haas > wrote: > > > On Tue, Aug 1, 2017 at 4:00 PM, Ildus K > > wrote: > > > It's a workaround. DatumGetTSVector and > > > DatumGetTSVectorCopy will upgrade tsvector on the fly if it > > > h

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, 10 Aug 2017 11:46:55 -0400 Tom Lane wrote: > Alexander Korotkov writes: > > ... > > You have random mix of tabs and spaces here. > > It's worth running pgindent over your code before submitting. It > should be pretty easy to set that up nowadays, see > src/tools/pgindent/README. (If

Re: [HACKERS] Remove 1MB size limit in tsvector

Alexander Korotkov writes: > ... > You have random mix of tabs and spaces here. It's worth running pgindent over your code before submitting. It should be pretty easy to set that up nowadays, see src/tools/pgindent/README. (If you find any portability problems while trying to install pgindent, p

Re: [HACKERS] Remove 1MB size limit in tsvector

On Thu, Aug 10, 2017 at 7:37 AM, Michael Paquier wrote: > On Wed, Aug 9, 2017 at 6:38 PM, Robert Haas wrote: > > The patch doesn't really conform to our coding standards, though, so > > you need to clean it up (or, if you're not sure what you need to do, > > you need to have someone who knows ho

Re: [HACKERS] Remove 1MB size limit in tsvector

On Wed, Aug 9, 2017 at 7:38 PM, Robert Haas wrote: > On Tue, Aug 1, 2017 at 4:00 PM, Ildus K > wrote: > > It's a workaround. DatumGetTSVector and > > DatumGetTSVectorCopy will upgrade tsvector on the fly if it > > has old format. > > Hmm, that seems like a real fix, not just a workaround. If yo

Re: [HACKERS] Remove 1MB size limit in tsvector

On Wed, Aug 9, 2017 at 6:38 PM, Robert Haas wrote: > The patch doesn't really conform to our coding standards, though, so > you need to clean it up (or, if you're not sure what you need to do, > you need to have someone who knows how PostgreSQL code needs to look > review it for you). The documen

Re: [HACKERS] Remove 1MB size limit in tsvector

On Tue, Aug 1, 2017 at 4:00 PM, Ildus K wrote: > It's a workaround. DatumGetTSVector and > DatumGetTSVectorCopy will upgrade tsvector on the fly if it > has old format. Hmm, that seems like a real fix, not just a workaround. If you can transparently read the old format, there's no problem. Not

Re: [HACKERS] Remove 1MB size limit in tsvector

On Wed, 9 Aug 2017 09:01:44 +0200 Torsten Zuehlsdorff wrote: > On 01.08.2017 22:00, Ildus K wrote: > > On Tue, 1 Aug 2017 15:33:08 -0400 > > Robert Haas wrote: > > > >> On Tue, Aug 1, 2017 at 3:10 PM, Ildus K > >> wrote: > So this would break pg_upgrade for tsvector columns? > >>> >

Re: [HACKERS] Remove 1MB size limit in tsvector

On 01.08.2017 22:00, Ildus K wrote: On Tue, 1 Aug 2017 15:33:08 -0400 Robert Haas wrote: On Tue, Aug 1, 2017 at 3:10 PM, Ildus K wrote: So this would break pg_upgrade for tsvector columns? I added a function that will convert old tsvectors on the fly. It's the approach used in hstore bef

Re: [HACKERS] Remove 1MB size limit in tsvector

On Tue, 1 Aug 2017 15:33:08 -0400 Robert Haas wrote: > On Tue, Aug 1, 2017 at 3:10 PM, Ildus K > wrote: > >> So this would break pg_upgrade for tsvector columns? > > > > I added a function that will convert old tsvectors on the fly. It's > > the approach used in hstore before. > > Does that

Re: [HACKERS] Remove 1MB size limit in tsvector

On Tue, Aug 1, 2017 at 3:10 PM, Ildus K wrote: >> So this would break pg_upgrade for tsvector columns? > > I added a function that will convert old tsvectors on the fly. It's the > approach used in hstore before. Does that mean the answer to the question that I asked is "yes, but I have a workaro

Re: [HACKERS] Remove 1MB size limit in tsvector

On Tue, 1 Aug 2017 14:56:54 -0400 Robert Haas wrote: > On Tue, Aug 1, 2017 at 10:08 AM, Ildus Kurbangaliev > wrote: > > Historically tsvector type can't hold more than 1MB data. > > I want to propose a patch that removes that limit. > > > > That limit is created by 'pos' field from WordEntry, wh

Re: [HACKERS] Remove 1MB size limit in tsvector

On Tue, Aug 1, 2017 at 10:08 AM, Ildus Kurbangaliev wrote: > Historically tsvector type can't hold more than 1MB data. > I want to propose a patch that removes that limit. > > That limit is created by 'pos' field from WordEntry, which have only > 20 bits for storage. > > In the proposed patch I re

[HACKERS] Remove 1MB size limit in tsvector

Hello, hackers! Historically tsvector type can't hold more than 1MB data. I want to propose a patch that removes that limit. That limit is created by 'pos' field from WordEntry, which have only 20 bits for storage. In the proposed patch I removed this field and instead of it I keep offsets only

Re: [HACKERS] Remove old comments in dependencies.c and README.dependencies

> Agreed. Removed those comments. Thanks for the patch. Thanks! On 2017/07/27 0:44, Alvaro Herrera wrote: atorikoshi wrote: Attached patch removes the comments about min_group_size. Agreed. Removed those comments. Thanks for the patch. -- Atsushi Torikoshi NIPPON TELEGRAPH AND TELEPH

Re: [HACKERS] Remove old comments in dependencies.c and README.dependencies

atorikoshi wrote: > Attached patch removes the comments about min_group_size. Agreed. Removed those comments. Thanks for the patch. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers

[HACKERS] Remove old comments in dependencies.c and README.dependencies

Hi, I found some comments which are not implemented. As far as I have examined, these comments refer to min_group_size, but min_group_size was decided not to adopt and removed[1], so it seems these comments also should be removed. [1] https://www.postgresql.org/message-id/cakjs1f_vuck+qbxqsh4

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

On Mon, Jun 12, 2017 at 9:03 AM, Ashutosh Bapat wrote: > On Mon, Jun 12, 2017 at 3:50 PM, amul sul wrote: >> On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote: >> [...] >>> I committed this with fixes for those issues, plus I renamed the macro >>> to partition_bound_accepts_nulls, which I thin

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

On Mon, Jun 12, 2017 at 3:50 PM, amul sul wrote: > On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote: > [...] >> I committed this with fixes for those issues, plus I renamed the macro >> to partition_bound_accepts_nulls, which I think is more clear. >> > partition_bound_accepts_nulls() will alw

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

On Wed, May 17, 2017 at 10:22 PM, Robert Haas wrote: [...] > I committed this with fixes for those issues, plus I renamed the macro > to partition_bound_accepts_nulls, which I think is more clear. > partition_bound_accepts_nulls() will alway yield true for a range partitioning case, because in Rel

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

> I committed this with fixes for those issues, plus I renamed the macro > to partition_bound_accepts_nulls, which I think is more clear. Thanks Robert.

Re: [HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

On Wed, May 17, 2017 at 6:53 AM, Jeevan Ladhe wrote: > As discussed in default partition thread[1], here is the patch to remove > has_null from PartitionBoundInfoData structure. > Basically flag has_null is not needed and null_index can be checked if the > current bound is having a null value or n

[HACKERS] remove unnecessary flag has_null from PartitionBoundInfoData

Hi, As discussed in default partition thread[1] , here is the patch to remove has_null from PartitionBoundInfoData structure. Basically flag has_null is not needed and null_index can be

Re: [HACKERS] Remove pre-10 compatibility code in hash index

On Wed, May 10, 2017 at 9:17 AM, Robert Haas wrote: > On Tue, May 9, 2017 at 1:41 AM, Amit Kapila wrote: >> Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash >> index version and obviates the need for backward compatibility code >> added by commit 293e24e507838733aba4748b514536a

Re: [HACKERS] Remove pre-10 compatibility code in hash index

On Tue, May 9, 2017 at 1:41 AM, Amit Kapila wrote: > Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash > index version and obviates the need for backward compatibility code > added by commit 293e24e507838733aba4748b514536af2d39d7f2. The same > has been mentioned in the commit me

[HACKERS] Remove pre-10 compatibility code in hash index

Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash index version and obviates the need for backward compatibility code added by commit 293e24e507838733aba4748b514536af2d39d7f2. The same has been mentioned in the commit message, please find attached patch to remove the pre-10 compa

Re: [HACKERS] Remove dead interfaces added by mistake in 7c4f52409

On Sun, Apr 23, 2017 at 8:15 AM, Petr Jelinek wrote: > Hi, > > Seems like couple of declarations for couple of functions we never > actually implemented and are not used got past review of logical > replication support for initial copy path (commit 7c4f52409). > > Attached patch gets rid of them.

[HACKERS] Remove dead interfaces added by mistake in 7c4f52409

Hi, Seems like couple of declarations for couple of functions we never actually implemented and are not used got past review of logical replication support for initial copy path (commit 7c4f52409). Attached patch gets rid of them. -- Petr Jelinek http://www.2ndQuadrant.com/

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On 2017/04/13 12:11, Fujii Masao wrote: > On Wed, Apr 12, 2017 at 10:32 AM, Amit Langote > wrote: >> On 2017/04/12 0:22, Fujii Masao wrote: >>> On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote >>> wrote: On 2017/04/07 0:56, Fujii Masao wrote: > On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote >

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On Wed, Apr 12, 2017 at 10:32 AM, Amit Langote wrote: > On 2017/04/12 0:22, Fujii Masao wrote: >> On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote >> wrote: >>> On 2017/04/07 0:56, Fujii Masao wrote: On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote wrote: > It seems pg_stat_progress_vacuu

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On 2017/04/12 0:22, Fujii Masao wrote: > On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote > wrote: >> On 2017/04/07 0:56, Fujii Masao wrote: >>> On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote >>> wrote: It seems pg_stat_progress_vacuum is not supposed to appear in the table titled "Collected

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote wrote: > On 2017/04/07 0:56, Fujii Masao wrote: >> On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote >> wrote: >>> It seems pg_stat_progress_vacuum is not supposed to appear in the table >>> titled "Collected Statistics Views". It was added by c16dc1aca.

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On 2017/04/07 0:56, Fujii Masao wrote: > On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote > wrote: >> It seems pg_stat_progress_vacuum is not supposed to appear in the table >> titled "Collected Statistics Views". It was added by c16dc1aca. Attached >> patch fixes that. > > Instead, it should appe

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote wrote: > It seems pg_stat_progress_vacuum is not supposed to appear in the table > titled "Collected Statistics Views". It was added by c16dc1aca. Attached > patch fixes that. Instead, it should appear in the table of "Dynamic Statistics Views" beca

[HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

It seems pg_stat_progress_vacuum is not supposed to appear in the table titled "Collected Statistics Views". It was added by c16dc1aca. Attached patch fixes that. Thanks, Amit >From 779fd54f0e30455e0393252a4ba4514d23e0af15 Mon Sep 17 00:00:00 2001 From: amit Date: Tue, 4 Apr 2017 10:16:53 +0900

Re: [HACKERS] Remove !isTemp buffile.c code

On Sat, Mar 25, 2017 at 10:25 PM, Andres Freund wrote: > buffile.c currently has a fair amount of code dependant on > BufFile->isTemp - which afaics hasn't ever been used. I'd rather remove > that code, before potentially (further) breaking the unused code. I think this is a good idea, but then

[HACKERS] Remove !isTemp buffile.c code

Hi, A nearby thread [1], does some work on buffile.c. Amongst others it renames isTemp to something else (not sure yet why - the new name is about as apt as before), but that's not really what I want to talk about here. buffile.c currently has a fair amount of code dependant on BufFile->isTemp -

Re: [HACKERS] Remove obsolete text from hash/README

On Tue, Mar 14, 2017 at 10:22 PM, Amit Kapila wrote: > As pointed out by Tom [1], attached is a patch to remove obsolete text > from src/backend/access/hash/README Heh, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hacker

[HACKERS] Remove obsolete text from hash/README

As pointed out by Tom [1], attached is a patch to remove obsolete text from src/backend/access/hash/README [1] - https://www.postgresql.org/message-id/5515.1489514099%40sss.pgh.pa.us -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com fix_hash_index_readme_v1.patch Descript

Re: [HACKERS] remove deprecated COMMENT ON RULE syntax

On Wed, Feb 22, 2017 at 8:05 PM, Tom Lane wrote: > Peter Eisentraut writes: >> There is support for COMMENT ON RULE without specifying a table >> name, for upgrading from pre-7.3 instances. I think it might be time >> for that workaround to go. > > No objection here. Yeah, probably so. -- Ro

Re: [HACKERS] remove deprecated COMMENT ON RULE syntax

Peter Eisentraut writes: > There is support for COMMENT ON RULE without specifying a table > name, for upgrading from pre-7.3 instances. I think it might be time > for that workaround to go. No objection here. regards, tom lane -- Sent via pgsql-hackers mailing list

[HACKERS] remove deprecated COMMENT ON RULE syntax

There is support for COMMENT ON RULE without specifying a table name, for upgrading from pre-7.3 instances. I think it might be time for that workaround to go. Patch attached. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Trainin

Re: [HACKERS] remove floats from bootstrap scanner/parser

On 1/9/17 9:11 PM, Alvaro Herrera wrote: I happened to notice that we have dead code to parse floating point numbers in the boostrap scanner/parser. This seems unused since forever -- or, more precisely, I couldn't find any floats in 8.2's postgres.bki (the oldest I have around). I would just r

[HACKERS] remove floats from bootstrap scanner/parser

I happened to notice that we have dead code to parse floating point numbers in the boostrap scanner/parser. This seems unused since forever -- or, more precisely, I couldn't find any floats in 8.2's postgres.bki (the oldest I have around). I would just rip it out, per the attached. -- Álvaro He

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

On 12/23/16 7:26 PM, Tom Lane wrote: > David Steele writes: >> What about a ./configure option that basically removes the min/max >> limits of every setting where it makes sense? > > It's pretty much never the case that anything goes; for example, > are we going to insist that the code be able to

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

David Steele writes: > What about a ./configure option that basically removes the min/max > limits of every setting where it makes sense? It's pretty much never the case that anything goes; for example, are we going to insist that the code be able to respond sanely to negative checkpoint_timeout?

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

On 12/23/16 6:12 PM, Michael Paquier wrote: > On Sat, Dec 24, 2016 at 6:02 AM, David Steele wrote: >> On 12/23/16 10:24 AM, Tom Lane wrote: >>> Andres Freund writes: While it's not a particularly good idea to set it to 1s on a production system, I don't see why we need to prevent that.

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

On Sat, Dec 24, 2016 at 6:02 AM, David Steele wrote: > On 12/23/16 10:24 AM, Tom Lane wrote: >> Andres Freund writes: >>> While it's not a particularly good idea to set it to 1s on a production >>> system, I don't see why we need to prevent that. It's not like 30s is >>> likely to be a good idea

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

On 12/23/16 10:24 AM, Tom Lane wrote: > Andres Freund writes: >> While it's not a particularly good idea to set it to 1s on a production >> system, I don't see why we need to prevent that. It's not like 30s is >> likely to be a good idea either. > >> Hence I'd like to set the lower limit to 1s. >

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

Andres Freund writes: > While it's not a particularly good idea to set it to 1s on a production > system, I don't see why we need to prevent that. It's not like 30s is > likely to be a good idea either. > Hence I'd like to set the lower limit to 1s. OK, but the documentation for it needs some wo

Re: [HACKERS] Remove lower limit on checkpoint_timeout?

Hello Andres, for testing - like yesterday's 6ef2eba3f - it's annoying that checkpoint_timeout has 30s minimum. I've now locally patched that to be 1s a significant number of times. While it's not a particularly good idea to set it to 1s on a production system, I don't see why we need to preve

[HACKERS] Remove lower limit on checkpoint_timeout?

Hi, for testing - like yesterday's 6ef2eba3f - it's annoying that checkpoint_timeout has 30s minimum. I've now locally patched that to be 1s a significant number of times. While it's not a particularly good idea to set it to 1s on a production system, I don't see why we need to prevent that. It's

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On 11/7/16 12:43 AM, amul sul wrote: > On Mon, Nov 7, 2016 at 10:46 AM, Tsunakawa, Takayuki > wrote: >> >> The third paragraph may be redundant, I'm a bit inclined to leave it for >> kindness and completeness. The attached revised patch just correct the >> existing typo (large -> larger). >> >

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Tuesday, November 22, 2016, Robert Haas wrote: > On Fri, Nov 18, 2016 at 3:23 PM, Peter Eisentraut > > wrote: > > On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: > >> No, I'm not recommending a higher value, but just removing the doubtful > sentences of 512MB upper limit. The advantage is th

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Fri, Nov 18, 2016 at 3:23 PM, Peter Eisentraut wrote: > On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: >> No, I'm not recommending a higher value, but just removing the doubtful >> sentences of 512MB upper limit. The advantage is that eliminating this >> sentence will make a chance for use

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Mon, Nov 21, 2016 at 7:46 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> > shared_buffers tps >> > 256MB 990 >> > 512MB 813 >> > 1GB 1189 >> > 2GB 2258 >> > 4GB 5003 >> > 8GB 5062 >> > >

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > > shared_buffers tps > > 256MB 990 > > 512MB 813 > > 1GB 1189 > > 2GB 2258 > > 4GB 5003 > > 8GB 5062 > > > > "512MB is the largest effective size" seems to be a superstition, alt

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Mon, Nov 21, 2016 at 5:22 AM, Tsunakawa, Takayuki wrote: > From: Tsunakawa, Takayuki/綱川 貴之 >> Thank you, I'll try the read-write test with these settings on the weekend, >> when my PC is available. I understood that your intention is to avoid being >> affected by checkpointing and WAL segment

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: Tsunakawa, Takayuki/綱川 貴之 > Thank you, I'll try the read-write test with these settings on the weekend, > when my PC is available. I understood that your intention is to avoid being > affected by checkpointing and WAL segment creation. The result looks nice as follows. I took the mean valu

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On 11/17/16 12:30 AM, Tsunakawa, Takayuki wrote: > No, I'm not recommending a higher value, but just removing the doubtful > sentences of 512MB upper limit. The advantage is that eliminating this > sentence will make a chance for users to try best setting. I think this is a good point. The inf

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > > I think the reason why increasing shared_buffers didn't give better > performance for read-only tests than you expect is that the relation files > are cached in the filesystem cache.

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Fri, Nov 11, 2016 at 10:03 PM, Amit Kapila wrote: > Right, but for other platforms, the recommendation seems to be 25% of > RAM, can we safely say that for Windows as well? As per test results > in this thread, it seems the read-write performance degrades when > shared buffers have increased f

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Tue, Nov 15, 2016 at 7:14 AM, Tsunakawa, Takayuki wrote: > From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila >> Okay, not a problem. However, I am not sure the results in this thread >> are sufficient proof as for read-only tests,

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > Okay, not a problem. However, I am not sure the results in this thread > are sufficient proof as for read-only tests, there is no noticeable win > by increasing shared buffers and read

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Sun, Nov 13, 2016 at 1:23 AM, Jeff Janes wrote: > On Mon, Nov 7, 2016 at 7:03 PM, Amit Kapila wrote: >> >> On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes wrote: >> > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila >> > wrote: >> >> >> >> >> >> Isn't it somewhat strange that writes are showing big wi

  1   2   3   4   5   6   7   >