Re: 2018-03 Commitfest starts tomorrow

Hi, On 2018-03-01 00:42:25 -0500, Tom Lane wrote: > As of right now, there are 229 entries in this commitfest (not counting > the items already committed or RWF). > > It's hard for me to tell for sure, because the activity log page doesn't > stretch back far enough, but I think about 40 of those

Re: Changing the autovacuum launcher scheduling; oldest table first algorithm

On Fri, Mar 2, 2018 at 4:51 PM, Andres Freund wrote: > Hi, > > On 2018-02-28 18:04:27 +0900, Masahiko Sawada wrote: >> I've created the new thread for the changing AV launcher scheduling. >> The problem of AV launcher scheduling is described on [1] but I >> summarize it here. > > This is a new pat

Re: 2018-03 Commitfest Summary (Andres #4)

On 2 March 2018 at 15:52, Andres Freund wrote: > > Yay! Also, sorry for all the spam today. > Quite the opposite, thanks for keeping everyone up to date and keeping things on track. I'm hoping to resurrect the ProcSignal based memory context dump soon, maybe for final CF since it's minor. Sti

Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Fri, Mar 2, 2018 at 4:38 PM, Andres Freund wrote: > Hi, > > On 2018-01-26 17:00:26 +0900, Michael Paquier wrote: >> Another topic that I would like to discuss is how this interface is fit >> for the buildfarm code. After hacking my stuff, I have looked at the >> buildfarm code to notice that t

Re: zheap: a new storage format for PostgreSQL

Hello Amit, At EnterpriseDB, we (me and some of my colleagues) are working from more than a year on the new storage format in which only the latest version of the data is kept in main storage and the old versions are moved to an undo log. [...] This looks more than great! *We’ve shown the

Re: Suspicious call of initial_cost_hashjoin()

David Steele wrote: > On 12/22/17 6:13 AM, Thomas Munro wrote: > > On Fri, Dec 22, 2017 at 10:45 PM, Antonin Houska wrote: > >> try_partial_hashjoin_path() passes constant true to for the parallel_hash > >> argument of initial_cost_hashjoin(). Shouldn't it instead pass the > >> parallel_hash arg

Re: 2018-03 Commitfest Summary (Andres #4)

Hi, On 2018-03-02 16:02:35 +0800, Craig Ringer wrote: > Quite the opposite, thanks for keeping everyone up to date and keeping > things on track. Thanks. > I'm hoping to resurrect the ProcSignal based memory context dump soon, > maybe for final CF since it's minor. Say what? That's definitely

Re: Changing the autovacuum launcher scheduling; oldest table first algorithm

On Fri, Mar 2, 2018 at 5:00 PM, Masahiko Sawada wrote: > On Fri, Mar 2, 2018 at 4:51 PM, Andres Freund wrote: >> Hi, >> >> On 2018-02-28 18:04:27 +0900, Masahiko Sawada wrote: >>> I've created the new thread for the changing AV launcher scheduling. >>> The problem of AV launcher scheduling is des

RE: zheap: a new storage format for PostgreSQL

From: Amit Kapila [mailto:amit.kapil...@gmail.com] > At EnterpriseDB, we (me and some of my colleagues) are working from more > than a year on the new storage format in which only the latest version of > the data is kept in main storage and the old versions are moved to an undo > log. We call this

Re: WIP Patch: Precalculate stable functions, infrastructure v1

Hello! I fixed the failure that Thomas pointed out to me, and I'm finishing work on it, but it took me a while to study this part of the executor.. On 02-03-2018 0:11, Andres Freund wrote: Hi, On 2018-02-01 08:01:48 +0300, Marina Polyakova wrote: > ISTM, there might be some value to conside

Re: Disabling src/test/[ssl|ldap] when not building with SSL/LDAP support

On Wed, Feb 28, 2018 at 10:02:37AM -0500, Peter Eisentraut wrote: > On 2/24/18 18:29, Michael Paquier wrote: >> Sure. But then I think that it would be nice to show up on screen the >> reason why the test failed if possible. As of now if SSL is missing the >> whole run shows in red without provid

Re: [HACKERS] log_destination=file

On Fri, Mar 2, 2018 at 8:27 AM, Andres Freund wrote: > Hi, > > On 2018-01-20 14:51:12 +0200, Magnus Hagander wrote: > > Finally found myself back at this one, because I still think this is a > > problem we definitely need to adress (whether with this file or not). > > This has an open CF entry fo

Re: [PATCH] Improve geometric types

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested Unfortunately according to http://commitfest.cputube.org/ this patch does

Re: 2018-03 CFM

Hello David, > > Thank you for volunteering! > > > > I would like to be CFM assistant, if you need one :) > > Right now Andres and I are doing triage on the patches to determine what is > likely to be committed in this CF. > > I would be very interested in your input. I generally start with pa

Re: autovacuum: change priority of the vacuumed tables

On Thu, 1 Mar 2018 23:39:34 -0800 Andres Freund wrote: > Hi, > > On 2018-02-19 17:00:34 +0100, Tomas Vondra wrote: > > I have a hard time understanding how adding yet another autovacuum > > table-level knob makes the DBA's life any easier. Especially when > > the behavior is so unreliable and do

Re: 2018-03 Commitfest Summary (Andres #3)

On Thu, 1 Mar 2018 20:34:11 -0800 Andres Freund wrote: > > - Custom compression methods > > RFC. While marked as ready for committer, I think this is mostly > because some high level design input is needed. It's huge, and so > far only seems to add already existing compression support. >

Re: [HACKERS] Bug in to_timestamp().

On Fri, Mar 02, 2018 at 12:58:57AM +0100, Dmitry Dolgov wrote: > > On 18 February 2018 at 18:49, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > > On 17 February 2018 at 10:02, Arthur Zakirov > wrote: > > > ... > > > I think it could be fixed by another patch. But I'm not sure that it > > > will

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 9:23 AM, Alvaro Herrera wrote: > I think it was impolite to post this on the very same day the commitfest > started. We have enough patches as it is ... > I can understand your concern, but honestly, I have no intention to hinder the current commit fest work. We are prepa

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 9:29 AM, Mark Kirkwood wrote: > On 02/03/18 16:53, Alvaro Herrera wrote: > >> I think it was impolite to post this on the very same day the commitfest >> started. We have enough patches as it is ... >> > > To be fair - he did say things like "wanting feedback..." and "shows

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 1:35 PM, Fabien COELHO wrote: > > Hello Amit, > >> At EnterpriseDB, we (me and some of my colleagues) are working from more >> than a year on the new storage format in which only the latest version of >> the data is kept in main storage and the old versions are moved to an u

RE: Optimize Arm64 crc32c implementation in Postgresql

Hi, Thanks for all your comments. > Could you show whether it actually improves performance? Usually bulk loading > data with parallel COPYs is a good way to hit this code path. The mini benchmark code: #include #include #include #include #include "port/pg_crc32c.h" long int GetTi

Re: 2018-03 Commitfest Summary (Andres #1)

Hello andres & Tom, A bit concerned that we're turning pgbench into a kitchen sink. I do not understand "kitchen sink" expression in this context, and your general concerns about pgbench in various comments in your message. We're adding a lot of stuff to pgbench that only a few people use.

Re: Suspicious call of initial_cost_hashjoin()

On Fri, Mar 2, 2018 at 9:06 PM, Antonin Houska wrote: > David Steele wrote: >> Does this look right to you? > > Yes, this is what I meant. The patch applies cleanly and the code compiles > well. > >> If so, can you sign up as a reviewer and mark it Ready for Committer? > > Done. Thanks. > Actua

Re: 2018-03 Commitfest Summary (Andres #1)

Hi! On Thu, Mar 1, 2018 at 2:03 PM, Andres Freund wrote: > - GUC for cleanup index threshold > > NR. Open for over a year. Alexander Korotkov just tried to re-start > discussion. > > Not quite sure if it's realistic unless somebody familiar with the > code invests some time. > Right.

Re: 2018-03 Commitfest Summary (Andres #3)

On Fri, Mar 2, 2018 at 7:34 AM, Andres Freund wrote: > - Pluggable storage API > > NR. This unfortunately still seems far off. It's possible though that > we can split off some smaller pieces of work and get them committed? > I'm working on reordering patchset so that refactoring patches go

Re: 2018-03 Commitfest Summary (Andres #1)

Hello Tom, FWIW, I share Andres' concern that pgbench is being extended far past what anyone has shown a need for. If we had infinite resources this wouldn't be a big problem, but it's eating into limited committer hours and I'm not really convinced that we're getting adequate return. Anot

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 2:42 AM, Alexander Korotkov wrote: > > I think results representation should be improved. You show total size of > the database, but it's hard to understand how bloat degree was really > decreased, assuming that there are both update and append-only tables. So, I > prop

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 1:50 PM, Tsunakawa, Takayuki wrote: > From: Amit Kapila [mailto:amit.kapil...@gmail.com] >> At EnterpriseDB, we (me and some of my colleagues) are working from more >> than a year on the new storage format in which only the latest version of >> the data is kept in main stora

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 1:31 PM, Amit Kapila wrote: > On Fri, Mar 2, 2018 at 1:50 PM, Tsunakawa, Takayuki > wrote: > > From: Amit Kapila [mailto:amit.kapil...@gmail.com] > >> At EnterpriseDB, we (me and some of my colleagues) are working from more > >> than a year on the new storage format in whi

Re: postgres_fdw: perform UPDATE/DELETE .. RETURNING on a join directly

(2018/03/02 3:34), Tom Lane wrote: Robert Haas writes: This is another patch that got past me. Committed now. I'd be lying if I said I was filled with confidence that this was going to fix it, but I don't know what to do other than keep tinkering with it until we find something that works.

Re: Kerberos test suite

On Thu, Mar 1, 2018 at 4:43 AM, Peter Eisentraut wrote: > On 2/27/18 00:56, Thomas Munro wrote: >> FWIW it passes for me if I add this: >> >> +elsif ($^O eq 'freebsd') >> +{ >> + $krb5_bin_dir = '/usr/local/bin'; >> + $krb5_sbin_dir = '/usr/local/sbin'; > > I suppose you only need the

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Wed, Feb 28, 2018 at 12:06 AM, Claudio Freire wrote: > On Mon, Feb 26, 2018 at 10:20 PM, Masahiko Sawada > wrote: >> Thank you for updating patches! >> >> 0001 patch looks good to me except for the following unnecessary empty lines. >> >> +* If there are no indexes then we sho

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 8:44 AM, Andres Freund wrote: > On 2018-03-01 16:18:48 +0100, Magnus Hagander wrote: > > On Thu, Mar 1, 2018 at 9:04 AM, Andres Freund > wrote: > > > > > On 2018-03-01 12:56:35 +0500, Andrey Borodin wrote: > > > > I've tried to rebase this patch to 10 and, despite minor re

Re: Allow workers to override datallowconn

On Fri, Feb 23, 2018 at 7:55 PM, Magnus Hagander wrote: > On Fri, Feb 23, 2018 at 7:52 PM, Tom Lane wrote: > >> Magnus Hagander writes: >> > Here's another attempt at moving this one forward. Basically this adds a >> > new GucSource being GUC_S_CLIENT_EARLY. It now runs through the >> parameter

Re: [PROPOSAL] Shared Ispell dictionaries

Hello, Thank you for your comments. On Thu, Mar 01, 2018 at 08:31:49PM -0800, Andres Freund wrote: > Hi, > > On 2018-02-07 19:28:29 +0300, Arthur Zakirov wrote: > > + { > > + {"max_shared_dictionaries_size", PGC_POSTMASTER, RESOURCES_MEM, > > + gettext_noop("Sets th

Re: [HACKERS] path toward faster partition pruning

Thanks for your comments. On 2018/03/02 4:13, Robert Haas wrote: > On Wed, Feb 28, 2018 at 11:53 PM, Amit Langote > wrote: >> Attached updated patches. > > + memcpy(part_scheme->partsupfunc, partkey->partsupfunc, > + sizeof(FmgrInfo) * partnatts); > > You can't copy an Fm

Re: [PATCH] Verify Checksums during Basebackups

On Wed, Feb 28, 2018 at 7:08 PM, Michael Banck wrote: > Hi, > > some installations have data which is only rarerly read, and if they are > so large that dumps are not routinely taken, data corruption would only > be detected with some large delay even with checksums enabled. > I think this is a

Re: [HACKERS] path toward faster partition pruning

On 2018/03/02 11:12, David Rowley wrote: > On 2 March 2018 at 08:13, Robert Haas wrote: >> I don't like the comments at the top of partprune.c very much. It >> seems strange to document individual functions here; those functions >> can (and should) be documented in their individual header comment

ALTER TABLE does not check for column existence before starting operations

Hi While working on a big table recently, I noticed that ALTER TABLE does not check for column existence in operations like SET NOT NULL before starting working on the table, for instance adding a primary key. It is thus possible, if a typo has been made, to generate a long lock and a lot of WA

perltidy version

Our instructions in src/tools/pgindent/README says to make sure we use perltidy version v20090616. However, this version no longer appears to be available for download on the link we provide -- the oldest one available is 20140328. Is it perhaps time to move up to a newer version? Or failing that,

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 11:35 PM, Alexander Korotkov wrote: > On Fri, Mar 2, 2018 at 1:31 PM, Amit Kapila wrote: >> On Fri, Mar 2, 2018 at 1:50 PM, Tsunakawa, Takayuki >> wrote: >> > Wonderful! BTW, what "z" stand for? Ultimate? >> >> There is no special meaning to 'z'. We have discussed quite

Re: 2018-03 CFM

> Hello David, > This data is worth cross-checking with http://commitfest.cputube.org/ > though. For instance, the "Improve geometric types" patch doesn't apply. > I already notified the author. I'll try to write a script that exports > data from this site as well to make cross-checking easier. O

Re: 2018-03 CFM

On Fri, Mar 2, 2018 at 12:45 PM, Aleksander Alekseev < a.aleks...@postgrespro.ru> wrote: > > Hello David, > > > This data is worth cross-checking with http://commitfest.cputube.org/ > > though. For instance, the "Improve geometric types" patch doesn't apply. > > I already notified the author. I'll

Re: Better Upgrades

On 6 February 2018 at 03:13, Craig Ringer wrote: > On 6 February 2018 at 09:51, Joshua D. Drake wrote: >> >> On 02/05/2018 04:09 PM, David Fetter wrote: >> >>> Does this seem worth coding up in its current form? >> >> No. The pg_upgrade utility is awesome and I have commended Bruce on >> multiple

Re: 2018-03 CFM

Hello Magnus, > You do realize we have the actual source database available, I hope? Since > it's our own system... There is no need to scrape the data back out -- if > we can just define what kind of reports we want, we can trivially run it on > the source database. Or if we want it more often, w

Re: perltidy version

Magnus Hagander writes: > Our instructions in src/tools/pgindent/README says to make sure we use > perltidy version v20090616. However, this version no longer appears to be > available for download on the link we provide -- the oldest one available > is 20140328. It's available via MetaCPAN: htt

Re: perltidy version

On Fri, Mar 2, 2018 at 1:30 PM, Dagfinn Ilmari Mannsåker wrote: > Magnus Hagander writes: > > > Our instructions in src/tools/pgindent/README says to make sure we use > > perltidy version v20090616. However, this version no longer appears to be > > available for download on the link we provide -

Re: [HACKERS] Surjective functional indexes

On 01.03.2018 22:48, Andres Freund wrote: Hi, I still don't think, as commented upon by Tom and me upthread, that we want this feature in the current form. Your arguments about layering violations seem to be counteracted by the fact that ProjectionIsNotChanged() basically appears to do purely

Re: [HACKERS] path toward faster partition pruning

On Fri, Mar 2, 2018 at 1:22 AM, Amit Langote wrote: > But I realized we don't need the coercion. Earlier steps would have > determined that the clause from which the expression originated contains > an operator that is compatible with the partitioning operator family. If > so, the type of the ex

Re: [HACKERS] Bug in to_timestamp().

> On 2 March 2018 at 10:33, Arthur Zakirov wrote: > > The fix you proposed isn't related with the initial report [1] by Amul > Sul, IMHO. The patch tries to fix that behaviour and additionally tries > to be more smart in handling and matching separator characters within > input and format strings.

Re: [HACKERS] Bug in to_timestamp().

On Fri, Mar 02, 2018 at 01:44:53PM +0100, Dmitry Dolgov wrote: > Well, I'm not sure that it's completely unrelated, but I see your point - it > makes sense to discuss this and move forward in small steps. So, if there are > no objections I'll mark this patch as ready. Thank you! -- Arthur Zakiro

Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Thu, Mar 01, 2018 at 10:08:06PM -0800, Andres Freund wrote: > On 2018-01-26 17:00:26 +0900, Michael Paquier wrote: >> +elsif (defined($ENV{oldsrc}) && >> +defined($ENV{oldbindir}) && >> +defined($ENV{oldlibdir})) >> +{ >> +# A run is wanted on an old version as base. >> +$oldsrc

Re: [PATCH] pg_hba.conf : new auth option : clientcert=verify-full

On Fri, Feb 16, 2018 at 4:45 PM, Julian Markwort < julian.markw...@uni-muenster.de> wrote: > Dear Postgresql Hackers, > > as of now, pg_hba.conf allows us to enable authentification by > certificate through the auth-method "cert", in which case the user must > provide a valid certificate with a ce

Re: Synchronous replay take III

Thanks Thomas, appreciate the rebase and the work you've done on this. I should have some time to test this out over the weekend. -Adam

Re: Rewriting the test of pg_upgrade as a TAP test - take two

On Fri, Mar 02, 2018 at 06:33:55PM +1030, Andrew Dunstan wrote: > TestUpgradeXversion.pm is different in a number of respects from the > inbuilt test regime. It doesn't run the normal regression suite to set > up a test. Rather, it saves out the installed binaries and data > directory of the buildf

Re: Online enabling of checksums

On Wed, Feb 28, 2018 at 10:07 PM, Tomas Vondra wrote: > On 02/28/2018 08:42 PM, Alvaro Herrera wrote: > > I noticed that pg_verify_checksum takes an "-o oid" argument to only > > check the relation with that OID; but that's wrong, because the number > > is a relfilenode, not an OID (since it's co

Re: Online enabling of checksums

On Wed, Feb 28, 2018 at 6:06 PM, Robert Haas wrote: > On Sun, Feb 25, 2018 at 9:54 AM, Magnus Hagander > wrote: > > Also if that wasn't clear -- we only do the full page write if there > isn't > > already a checksum on the page and that checksum is correct. > > Hmm. > > Suppose that on the maste

Re: zheap: a new storage format for PostgreSQL

Hello Amit, > Sometime back Robert has proposed a solution to reduce the bloat in > PostgreSQL [1] which has some other advantages of its own as well. To > recap, in the existing heap, we always create a new version of a tuple on > an update which must eventually be removed by periodic vacuuming

Re: ALTER TABLE does not check for column existence before starting operations

Hi Pierre, On 3/2/18 6:36 AM, Pierre Ducroquet wrote: > > While working on a big table recently, I noticed that ALTER TABLE does not > check for column existence in operations like SET NOT NULL before starting > working on the table, for instance adding a primary key. > It is thus possible, if

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada wrote: > Thank you for updating the patches! > > +/* > + * When a table has no indexes, vacuum the FSM at most every this > + * many dirty pages. With a default page size of 8kb, this value > + * basically means 8GB of dirtied pages. > + */ > +#defin

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire wrote: > On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada wrote: >> Thank you for updating the patches! >> >> +/* >> + * When a table has no indexes, vacuum the FSM at most every this >> + * many dirty pages. With a default page size of 8kb, this val

Last archived timestamp/xid for Point-in-Time Recovery

Hi pg-hackers, We archive the WAL to a remote storage and will perform Point-in-Time Recovery by replaying the log from that remote storage. Under heavy load, our archiving pipeline is not able to archive WAL quick enough and we would like to get more visibility on the lag. pg_stat_archiver is gr

Re: Rewriting the test of pg_upgrade as a TAP test - take two

Andrew Dunstan wrote: > One of the significant pluses to TestUpgradeXversion.pm is that it > tests upgrading quite a bit more than the standard regression > database. It also tests all the contrib databases and the isolation > and pl_regression databases. I think we should definitely be including

Re: perltidy version

Magnus Hagander wrote: > In that case, we should at least update our instructions for how to install > it. But that's definitely a better option than hosting our own copy. But surely the idea of updating the version to use should be considered further? Maybe they have even improved the output ;-

Re: Online enabling of checksums

Magnus Hagander wrote: > On Wed, Feb 28, 2018 at 10:07 PM, Tomas Vondra > I'd argue this is merely a mistake in the --help text. Firstly, > > relfilenodes are OIDs too, so I don't think "-o" is incorrect. Secondly, > > the SGML docs actually say: > Yeah, that one is my fault. It used to say oid a

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 3:17 PM, Alvaro Herrera wrote: > Magnus Hagander wrote: > > On Wed, Feb 28, 2018 at 10:07 PM, Tomas Vondra < > tomas.von...@2ndquadrant.com > > > > I'd argue this is merely a mistake in the --help text. Firstly, > > > relfilenodes are OIDs too, so I don't think "-o" is inco

Re: Re: [HACKERS] Cached plans and statement generalization

Hi Konstantin, On 1/12/18 7:53 AM, Konstantin Knizhnik wrote: > > > On 12.01.2018 03:40, Thomas Munro wrote: >> On Sun, Jan 7, 2018 at 11:51 AM, Stephen Frost >> wrote: >>> * Konstantin Knizhnik (k.knizh...@postgrespro.ru) wrote: Updated version of the patch is attached. >>> This patch app

Re: [HACKERS] [PATCH] Improve geometric types

> I'm a bit confused how this patch has gone through several revisions > since, but has been marked as "ready for committer" since 2017-09-05. Am > I missing something? This is floating between commitfests for longer than a year. Aleksander Alekseev set it to "ready for committer", but Kyotaro HOR

Re: [HACKERS] PoC: full merge join on comparison clause

On 22.02.2018 21:42, Alexander Kuzmenkov wrote: Some basic joins work, but I couldn't properly test all the corner cases with different orderings, because they depend on a bug in vanilla merge joins [1]. The bug was fixed, so here is the rebased patch. The planner part of the patch is sta

Re:Re: [GSOC 18] Performance Farm Project

Hi Robert, Thanks for your advice! I agree very much with you. It is necessary to analyze and determine its functional requirements before developing a website. Hopefully in the exchange with Mr. Wong, we can discuss the function of this website as detail as possible. I see the Build Farm proj

Re: Re: reorganizing partitioning code

Hi Amit, On 2/16/18 3:36 AM, Amit Langote wrote: > > Attached updated version. This patch no longer applies and the conflicts do not appear to be trivial. I'm a bit confused about your comment in [1]: > I gave up on rebasing this patch yesterday as I couldn't finish it in > 5 minutes, but mayb

Re: perltidy version

Alvaro Herrera writes: > Magnus Hagander wrote: >> In that case, we should at least update our instructions for how to install >> it. But that's definitely a better option than hosting our own copy. > But surely the idea of updating the version to use should be considered > further? Maybe they h

Re: ALTER TABLE does not check for column existence before starting operations

On Friday, March 2, 2018 2:44:16 PM CET David Steele wrote: > Hi Pierre, > > On 3/2/18 6:36 AM, Pierre Ducroquet wrote: > > While working on a big table recently, I noticed that ALTER TABLE does not > > check for column existence in operations like SET NOT NULL before starting > > working on the t

Re: ALTER TABLE does not check for column existence before starting operations

Pierre Ducroquet writes: > On Friday, March 2, 2018 2:44:16 PM CET David Steele wrote: >> I recommend entering this patch in the 2018-09 CF so it doesn't get lost. > Thanks for the answer. > I saw that bug two days ago but I had no time then to do the patch. Had I > seen > the CF window was tha

Re: 2018-03 Commitfest Summary (Andres #4)

On 3/2/18 2:52 AM, Andres Freund wrote: > > Let's do this. Hell, this CF is large. Yeah it is. > I'll have a glass of wine at some point of this. Hope you did! I've gone through all your notes and will follow up on your recommendations where you have not already done so. Thanks, -- -David

Re: autovacuum: change priority of the vacuumed tables

On 3/2/18 4:07 AM, Ildus Kurbangaliev wrote: > On Thu, 1 Mar 2018 23:39:34 -0800 > Andres Freund wrote: > >> Hi, >> >> On 2018-02-19 17:00:34 +0100, Tomas Vondra wrote: >>> I have a hard time understanding how adding yet another autovacuum >>> table-level knob makes the DBA's life any easier. Esp

Re: ON CONFLICT DO UPDATE for partitioned tables

Amit Langote wrote: > Actually, after your comment on my original patch [1], I did make it work > for multiple levels by teaching the partition initialization code to find > a given partition's indexes that are inherited from the root table (that > is the table mentioned in command). So, after a

Re: ON CONFLICT DO UPDATE for partitioned tables

Amit Langote wrote: > Actually, after your comment on my original patch [1], I did make it work > for multiple levels by teaching the partition initialization code to find > a given partition's indexes that are inherited from the root table (that > is the table mentioned in command). So, after a

Re: [patch] BUG #15005: ANALYZE can make pg_class.reltuples inaccurate.

On 02.03.2018 02:49, Tom Lane wrote: I looked at this and don't think it really answers the question. What happens is that, precisely because we only slowly adapt our estimate of density towards the new measurement, we will have an overestimate of density if the true density is decreasing (even

Re: [HACKERS] path toward faster partition pruning

On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote wrote: > Looking at the rough interface sketch in your message, it seems that the > product of whatever steps we end up grouping into phase 1 should be > something that can be put into a Node tree (PartitionPruneContext?), > because we may need to attac

Re: perltidy version

Magnus Hagander writes: > On Fri, Mar 2, 2018 at 3:53 PM, Tom Lane wrote: >> +1. We're not that far away from it being time to run pgindent/perltidy, >> so now would be a good time to consider whether we like a newer version's >> result better. > For example, Debian ships with 20140328, which p

Re: [HACKERS] path toward faster partition pruning

On 2 March 2018 at 08:13, Robert Haas wrote: > 2. All processing of clauses should happen at plan time, not run time, > so that we're not repeating work. If, for example, a prepared query > is executed repeatedly, the clauses should get fully processed when > it's planned, and then the only thing

Re: [HACKERS] path toward faster partition pruning

On 3 March 2018 at 04:47, Robert Haas wrote: > On Fri, Mar 2, 2018 at 6:21 AM, Amit Langote > wrote: >> Looking at the rough interface sketch in your message, it seems that the >> product of whatever steps we end up grouping into phase 1 should be >> something that can be put into a Node tree (Pa

Re: zheap: a new storage format for PostgreSQL

On Fri, Mar 2, 2018 at 5:35 AM, Alexander Korotkov wrote: > I would propose "zero-bloat heap" disambiguation of zheap. Seems like fair > enough explanation for me without need to rename :) It will be possible to bloat a zheap table in certain usage patterns. For example, if you bulk-load the tab

Re: Optimize Arm64 crc32c implementation in Postgresql

Hi, On 2018-03-02 09:42:22 +, Yuqi Gu wrote: > > Could you show whether it actually improves performance? Usually bulk > > loading data with parallel COPYs is a good way to hit this code path. > > The mini benchmark code: I'd be more interested in a benchmark using postgres itself... > > Wh

Re: [GSOC 18] Performance Farm Project

Hi Hongyuan, On Thu, Mar 01, 2018 at 05:56:07PM +0800, 马来酸 wrote: > Dear Sir, > Hi, my name is Hongyuan Ma. I am a junior student in software engineering in > Shanghai.I am interested in the idea "Develop Performance Farm Database and > Website".I started developing web applications since my sop

Re: Rangejoin rebased

On 16.01.2018 10:49, Jeff Davis wrote: My proposed fix is to make an internal opfamily identical to the external one, such that it's not recognized as part of the same EC, and the planner won't try to eliminate it. It loses out on potential optimizations, but those are mostly theoretical since th

Re: [PATCH] Opclass parameters

В письме от 1 марта 2018 23:02:20 пользователь Oleg Bartunov написал: > > 2. Your patch does not provide any example of your new tool usage. In my > > prototype patch I've shown the implementation of opclass options for > > intarray. May be you should do the same. (Use my example it will be more >

Re: Re: reorganizing partitioning code

Hi David. On Fri, Mar 2, 2018 at 11:53 PM, David Steele wrote: > Hi Amit, > > On 2/16/18 3:36 AM, Amit Langote wrote: >> >> Attached updated version. > > This patch no longer applies and the conflicts do not appear to be trivial. > > I'm a bit confused about your comment in [1]: > >> I gave up on

Re: [HACKERS] path toward faster partition pruning

On Fri, Mar 2, 2018 at 10:54 AM, David Rowley wrote: > I don't think building it is going to cost a huge amount. Presumably, > there are not many partitioned tables with 10 rows, so probably having > the get_partitions_from_clauses work as quickly as possible is better > than saving 100 nanosecond

Re: Online enabling of checksums

On 03/02/2018 03:22 PM, Magnus Hagander wrote: > > > On Fri, Mar 2, 2018 at 3:17 PM, Alvaro Herrera > wrote: > > Magnus Hagander wrote: > > On Wed, Feb 28, 2018 at 10:07 PM, Tomas Vondra > mailto:tomas.von...@2ndquadrant.com> > > > > I'd argue thi

Re: New gist vacuum.

Andrey Borodin writes: > So, I agree, unconditional counting is a good idea. Here's the v3 patch. Pushed with trivial cosmetic adjustments. I've marked the CF entry as committed; please make a new CF entry in 2018-09 for the other patch. I'd also suggest starting a new email thread for that. L

Re: [GSOC 18] Performance Farm Project

On Thu, Mar 01, 2018 at 02:31:08PM -0500, Robert Haas wrote: > On Thu, Mar 1, 2018 at 4:56 AM, 马来酸 wrote: > > Hi, my name is Hongyuan Ma. I am a junior student in software engineering in > > Shanghai.I am interested in the idea "Develop Performance Farm Database and > > Website".I started developi

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 8:35 AM, Magnus Hagander wrote: > Do we ever make hintbit changes on the standby for example? If so, it would > definitely cause problems. I didn't realize we did, actually... We do not. > I guess we could get there even if we don't by: > * All checksums are correct > * Ch

All Taxi Services need Index Clustered Heap Append

Hi, I work at a ride sharing company and we found a simple scenario that Postgres has a lot to improve at. After my talk at pgconf.ru Alexander Korotkov encouraged me to share my story and thoughts in -hackers. Story setting: - Amazon RDS (thus vanilla unpatchable postgres), synchronuous_commit

Re: Online enabling of checksums

On Fri, Mar 2, 2018 at 2:44 AM, Andres Freund wrote: > And even more so, I'm not even sure it makes sense to try to get this > into v11. This is a medium-large complicated feature, submitted to the > last CF for v11. That's pretty late. Now, Magnus is a committer, but > nevertheless... Yeah, I

Re: [HACKERS] Early locking option to parallel backup

On Fri, Mar 2, 2018 at 2:29 AM, Andres Freund wrote: > There seems to to be consensus in this thread that the approach Lucas > proposed isn't what we want, and that instead some shared lock based > approach is desirable. As that has been the case for ~1.5 months, I > propose we mark this as retur

Re: psql tab completion for ALTER INDEX SET

On Fri, Mar 2, 2018 at 3:52 PM, Masahiko Sawada wrote: > Hi, > > I found that tab completion for ALTER INDEX SET [tab] doesn't support > the reloptions of brin and gist. Attached patch adds "buffering", > "pages_per_range" and "autosummarize" options. Thanks for the patch! Committed. Regards, -

Re: Rangejoin rebased

On Fri, Mar 2, 2018 at 11:12 AM, Alexander Kuzmenkov wrote: > On 16.01.2018 10:49, Jeff Davis wrote: >> My proposed fix is to make an internal opfamily identical to the >> external one, such that it's not recognized as part of the same EC, >> and the planner won't try to eliminate it. It loses out

Re: [Patch] Checksums for SLRU files

On Thu, Mar 1, 2018 at 8:25 PM, Andres Freund wrote: > On 2018-02-02 11:37:34 +1300, Thomas Munro wrote: >> > 3. pg_upgrade isn't considered. This patch should provide upgrading SLRUs >> > to adopt changed useful size of page. That seems to be hardest patch of >> > this patch to be written. >> >

  1   2   >