Re: [HACKERS] [PATCH] Incremental sort (was: PoC: Partial sort)

On Mon, Feb 27, 2017 at 8:29 PM, Alexander Korotkov wrote: This patch needs to be rebased. 1. It fails while applying as below patching file src/test/regress/expected/sysviews.out Hunk #1 FAILED at 70. 1 out of 1 hunk FAILED -- saving rejects to file src/test/regress/expected/sysviews.out.rej p

[HACKERS] Thanks for the TAP framework

Hi It just occurred to me that much of what I've been doing recently would've been exceedingly difficult to write and even harder to debug without the TAP framework. I would've spent a LOT of time writing test scripts and wondering whether the bug was in my scripts or my Pg code. I still spend a

Re: [HACKERS] logical decoding of two-phase transactions

On 17 March 2017 at 23:59, Robert Haas wrote: > But that lock could need to be held for an unbounded period of time - > as long as decoding takes to complete - which seems pretty > undesirable. Yeah. We could use a recovery-conflict like mechanism to signal the decoding session that someone want

Re: [HACKERS] Patch to improve performance of replay of AccessExclusiveLock

On 18 March 2017 at 21:59, Simon Riggs wrote: > As Amit says, I don't see the gain from adding that to each xact state. > > I'd suggest refactoring my patch so that the existign > MyXactAccessedTempRel becomes MyXactFlags and we can just set a flag > in the two cases (temp rels and has-aels). That

Re: [HACKERS] logical decoding of two-phase transactions

On 19 March 2017 at 21:26, Petr Jelinek wrote: > I think only genam would need changes to do two-phase scan for this as > the catalog scans should ultimately go there. It's going to slow down > things but we could limit the impact by doing the two-phase scan only > when historical snapshot is in

Re: [HACKERS] Thanks for the TAP framework

Hello. For me Testgres https://github.com/postgrespro/testgres much better because I have the allergy for Perl. Unfortunately, it's not inside Postgres... 2017-03-20 10:21 GMT+03:00 Craig Ringer : > Hi > > It just occurred to me that much of what I've been doing recently > would've been exceedin

Re: [HACKERS] Logical decoding on standby

On 20 March 2017 at 14:57, Simon Riggs wrote: > 2.1 Why does call to ReplicationSlotAcquire() move earlier in > pg_logical_slot_get_changes_guts()? That appears to be an oversight from an earlier version where it looped over timelines in pg_logical_slot_get_changes_guts . Reverted. > 2.2 sendTi

Re: [HACKERS] logical decoding of two-phase transactions

On 20/03/17 09:32, Craig Ringer wrote: > On 19 March 2017 at 21:26, Petr Jelinek wrote: > >> I think only genam would need changes to do two-phase scan for this as >> the catalog scans should ultimately go there. It's going to slow down >> things but we could limit the impact by doing the two-pha

Re: [HACKERS] Logical decoding on standby

Hi, Have you checked how high the overhead of XLogReadDetermineTimeline is? A non-local function call, especially into a different translation-unit (no partial inlining), for every single page might end up being noticeable. That's fine in the cases it actually adds functionality, but for a master

Re: [HACKERS] identity columns

On 2/28/17, Peter Eisentraut wrote: > New patch that fixes everything. ;-) Great work! > On 1/4/17 19:34, Vitaly Burovoy wrote: >> 1. The fact COPY ignores GENERATED ALWAYS constraint (treats as >> GENERATED BY DEFAULT) should be mentioned as well as rules. > > fixed (documentation added) > > W

Re: [HACKERS] Size vs size_t

> On 16 Mar 2017, at 23:20, Tom Lane wrote: > > Thomas Munro writes: >> Naive replacement in new files (present in master but not in 9.6) with >> the attached script, followed by a couple of manual corrections where >> Size was really an English word in a comment, gets the attached diff. > > In

[HACKERS] Re: [COMMITTERS] pgsql: Add TAP tests for password-based authentication methods.

On 03/20/2017 02:32 AM, Peter Eisentraut wrote: On 3/17/17 05:37, Heikki Linnakangas wrote: Add TAP tests for password-based authentication methods. Tests all combinations of users with MD5, plaintext and SCRAM verifiers stored in pg_authid, with plain 'password', 'md5' and 'scram' authenticati

[HACKERS] [Proposal] Make the optimiser aware of partitions ordering

Hello, With native partitioning landing in Postgres 10, we (Julien Rouhaud and myself) had the idea for the following simple optimisation. This simple optimisation comes from a real use case. = Proposal = With range partitioning, we guarantee that each partition contains non- overlapp

Re: [HACKERS] PoC plpgsql - possibility to force custom or generic plan

2017-03-19 14:30 GMT+01:00 Petr Jelinek : > On 19/03/17 12:32, Pavel Stehule wrote: > > > > > > 2017-03-18 19:30 GMT+01:00 Petr Jelinek > >: > > > > On 16/03/17 17:15, David Steele wrote: > > > On 2/1/17 3:59 PM, Pavel Stehule wrote: > > >> Hi > >

Re: [HACKERS] logical decoding of two-phase transactions

> On 20 Mar 2017, at 11:32, Craig Ringer wrote: > > On 19 March 2017 at 21:26, Petr Jelinek wrote: > >> I think only genam would need changes to do two-phase scan for this as >> the catalog scans should ultimately go there. It's going to slow down >> things but we could limit the impact by doi

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On Sun, Mar 19, 2017 at 3:51 AM, Jim Nasby wrote: > On 3/16/17 12:48 PM, David Steele wrote: > >> This patch looks pretty straight forward and applies cleanly and >> compiles at cccbdde. >> >> It's not a straight revert, though, so still seems to need review. >> >> Jim, do you know when you'll ha

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hello, On 19.03.2017 21:45, Michael Banck wrote: So the patch I sent earlier creates the slot in ReceiveXlogStream() in receivewal.c, as that's where the temp slot gets created as well, but now I wonder whether that is maybe not the best place, as pg_receivewal also calls that function. The oth

Re: [HACKERS] [POC] A better way to expand hash indexes.

On Sat, Mar 18, 2017 at 10:59 PM, Mithun Cy wrote: > On Thu, Mar 16, 2017 at 10:55 PM, David Steele wrote: >> It does apply with fuzz on 2b32ac2, so it looks like c11453c and >> subsequent commits are the cause. They represent a fairly substantial >> change to hash indexes by introducing WAL log

Re: [HACKERS] Parallel Append implementation

>> 2. Next, estimate the cost of the non-partial paths. To do this, make >> an array of Cost of that length and initialize all the elements to >> zero, then add the total cost of each non-partial plan in turn to the >> element of the array with the smallest cost, and then take the maximum >> of th

Re: [HACKERS] Parallel Append implementation

On Fri, Mar 17, 2017 at 1:12 PM, Amit Khandekar wrote: >> - The substantive changes in add_paths_to_append_rel don't look right >> either. It's not clear why accumulate_partialappend_subpath is >> getting called even in the non-enable_parallelappend case. I don't >> think the logic for the case

Re: [HACKERS] logical decoding of two-phase transactions

> I thought about having special field (or reusing one of the existing fields) > in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin > as Petr suggested. Then this logic can reside in ReorderBufferCommit(). > However this is not solving problem with catcache, so I'm looking

Re: [HACKERS] wait events for disk I/O

On Sat, Mar 18, 2017 at 10:52 PM, Rushabh Lathia wrote: > > > On Sat, Mar 18, 2017 at 5:15 PM, Robert Haas wrote: >> >> On Fri, Mar 17, 2017 at 10:01 AM, Rushabh Lathia >> wrote: >> > I tried to cover all the suggestion in the attached latest patch. >> >> Committed. I reworded the documentation

Re: [HACKERS] logical replication access control patches

On 3/18/17 09:31, Petr Jelinek wrote: >> 0003 Add USAGE privilege for publications >> >> a way to control who can subscribe to a publication >> > Hmm IIUC this removes ability of REPLICATION role to subscribe to > publications. I am not quite sure I like that. Well, this is kind of the way with al

[HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > So was this 3340 line patch posted or discussed anyplace before it got > committed? I've mentioned a few times that I'm working on improving pg_dump regression tests and code coverage, which is what these were. I'm a bit surprised that it's,

Re: [HACKERS] logical decoding of two-phase transactions

On 17 March 2017 at 23:59, Robert Haas wrote: > On Thu, Mar 16, 2017 at 10:34 PM, Craig Ringer wrote: >> On 17 March 2017 at 08:10, Stas Kelvich wrote: >>> While working on this i’ve spotted quite a nasty corner case with aborted >>> prepared >>> transaction. I have some not that great ideas ho

Re: [HACKERS] logical decoding of two-phase transactions

> On 20 Mar 2017, at 15:17, Craig Ringer wrote: > >> I thought about having special field (or reusing one of the existing fields) >> in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin >> as Petr suggested. Then this logic can reside in ReorderBufferCommit(). >> However

Re: [HACKERS] [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

On Mon, Mar 20, 2017 at 8:33 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> So was this 3340 line patch posted or discussed anyplace before it got >> committed? > > I've mentioned a few times that I'm working on improving pg_dump > regression tests and code coverage, wh

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

On 3/20/17 08:33, Stephen Frost wrote: >> So was this 3340 line patch posted or discussed anyplace before it got >> committed? > I've mentioned a few times that I'm working on improving pg_dump > regression tests and code coverage, which is what these were. I'm a bit > surprised that it's, apparen

[HACKERS] Inadequate traces in TAP tests

If you look at this failure case you see: t/002_pg_dump.1..4449 # Looks like your test died before it could output anything. dubious Test returned status 255 (wstat 65280, 0xf

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 3/20/17 08:33, Stephen Frost wrote: > >> So was this 3340 line patch posted or discussed anyplace before it got > >> committed? > > I've mentioned a few times that I'm working on improving pg_dump > > regression tests and cod

Re: [HACKERS] Inadequate traces in TAP tests

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > If you look at this failure case > > you see: > > t/002_pg_dump.1..4449 > # Looks like your test died before it could ou

Re: [HACKERS] pageinspect and hash indexes

On Mon, Mar 20, 2017 at 9:31 AM, Amit Kapila wrote: > On Sat, Mar 18, 2017 at 5:13 PM, Ashutosh Sharma > wrote: >> On Sat, Mar 18, 2017 at 1:34 PM, Amit Kapila wrote: >>> On Sat, Mar 18, 2017 at 12:12 AM, Ashutosh Sharma >>> wrote: On Fri, Mar 17, 2017 at 10:54 PM, Jeff Janes wrote: >>>

[HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Mon, Mar 20, 2017 at 8:33 AM, Stephen Frost wrote: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> So was this 3340 line patch posted or discussed anyplace before it got > >> committed? > > > > I've mentioned a few times that I'm wor

Re: [HACKERS] logical decoding of two-phase transactions

On 20 March 2017 at 20:57, Stas Kelvich wrote: > >> On 20 Mar 2017, at 15:17, Craig Ringer wrote: >> >>> I thought about having special field (or reusing one of the existing fields) >>> in snapshot struct to force filtering xmax > snap->xmax or xmin = snap->xmin >>> as Petr suggested. Then this l

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Sat, Mar 18, 2017 at 5:40 AM, Robert Haas wrote: > On Fri, Mar 17, 2017 at 9:15 AM, Ashutosh Bapat > wrote: >> This set of patches fixes both of those things. > > 0001 changes the purpose of a function and then 0007 renames it. It > would be better to include the renaming in 0001 so that you'

Re: [HACKERS] logical decoding of two-phase transactions

> On 20 Mar 2017, at 16:39, Craig Ringer wrote: > > On 20 March 2017 at 20:57, Stas Kelvich wrote: >> >>> On 20 Mar 2017, at 15:17, Craig Ringer wrote: >>> I thought about having special field (or reusing one of the existing fields) in snapshot struct to force filtering xmax

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost writes: > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: >> ISTM that the test setup and breakdown code, both in individual tests >> and in PostgresNode.pm should be liberally sprinkled with diag() calls >> to make it easier to narrow down errors.. > While I'm generally i

Re: [HACKERS] Re: [COMMITTERS] pgsql: Add TAP tests for password-based authentication methods.

Heikki Linnakangas writes: > On 03/20/2017 02:32 AM, Peter Eisentraut wrote: >> This is missing an entry for tmp_check/ in .gitignore. But maybe we can >> do that globally instead of repeating it in every directory? > If we could also handle results and log globally, that would be nice. > But I

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost wrote: > Andrew, > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > > ISTM that the test setup and breakdown code, both in individual tests > > and in PostgresNode.pm should be liberally sprinkled with diag() calls > > to make it easier to narrow down errors.. > > While

Re: [HACKERS] [PATCH] Incremental sort

On 03/20/2017 11:33 AM, Alexander Korotkov wrote: Please, find rebased patch in the attachment. I had a quick look at this. * I'd love to have an explanation of what an Incremental Sort is, in the file header comment for nodeIncrementalSort.c. * I didn't understand the maxMem stuff in tuple

Re: [HACKERS] [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

On Mon, Mar 20, 2017 at 9:30 AM, Stephen Frost wrote: > While I certainly agree with that when it comes to new features, changes > in work-flow, bug fixes and other things, I'm really not sure that > requiring posting to the list and waiting for responses every time > someone wants to add some reg

Re: [HACKERS] Inadequate traces in TAP tests

On 20 Mar. 2017 22:10, "Tom Lane" wrote: FWIW, the problem I've got with the TAP tests is that when one fails in the buildfarm, you've got to dig through megabytes of all-alike-looking output just to try to determine which one failed; and once you do, you still know nothing because the script ou

Re: [HACKERS] Inadequate traces in TAP tests

On 03/20/2017 10:08 AM, Tom Lane wrote: > I am *absolutely* not in favor of adding anything to the scripts' routine > output, because it will just make this problem worse by bloating the > buildfarm logs even more. What I'd like to see is for the scripts to > always report something along the li

Re: [HACKERS] free space map and visibility map

On Sat, Mar 18, 2017 at 5:42 PM, Jeff Janes wrote: > Isn't HEAP2_CLEAN only issued before an intended HOT update? (Which then > can't leave the block as all visible or all frozen). I think the issue is > here is HEAP2_VISIBLE or HEAP2_FREEZE_PAGE. Am I reading this correctly, > that neither of

Re: [HACKERS] Inadequate traces in TAP tests

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > > > ISTM that the test setup and breakdown code, both in individual tests > > > and in PostgresNode.pm should be liberally sprinkled with diag() calls >

[HACKERS] Our feature change policy

On Sun, Mar 19, 2017 at 04:15:09PM -0400, Tom Lane wrote: > Stephen Frost writes: > > If we take your approach to its logical conclusion then we should be > > planning to maintain all user-facing deprecated features for as long as > > there is a version where it exists in a non-deprecated fashion,

[HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > I'm glad that you are working on fixing > pg_dump bugs and improving test coverage, but my gladness about that > does not extend to thinking that the processes which other people > follow for their work should be waived for yours. Sorry. To

Re: [HACKERS] Inadequate traces in TAP tests

Stephen Frost wrote: > Is there any hope of getting a "quiet" mode, where all the "ok" lines > aren't printed when things work..? Well, we currently have --verbose in PROVE_FLAGS. Maybe you can take it out, or even add --quiet or --QUIET (see the prove(1) manpage). -- Álvaro Herrera

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

On 2017-03-20 10:35:15 -0400, Stephen Frost wrote: > Robert, > > * Robert Haas (robertmh...@gmail.com) wrote: > > I'm glad that you are working on fixing > > pg_dump bugs and improving test coverage, but my gladness about that > > does not extend to thinking that the processes which other people >

Re: [HACKERS] [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

On Mon, Mar 20, 2017 at 10:35 AM, Stephen Frost wrote: > To be clear, I am not asking for any kind of special exception for > myself. > > I continue to be of the opinion that this entire discussion is quite > flipped from how we really should be running things- adding regression > tests to improve

Re: [HACKERS] Inadequate traces in TAP tests

Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > Is there any hope of getting a "quiet" mode, where all the "ok" lines > > aren't printed when things work..? > > Well, we currently have --verbose in PROVE_FLAGS. Maybe you can take it > out, or even add --quie

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Sun, Mar 19, 2017 at 3:05 AM, Pavan Deolasee wrote: > On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas wrote: >> On Wed, Mar 15, 2017 at 3:44 PM, Pavan Deolasee >> wrote: >> > I couldn't find a better way without a lot of complex infrastructure. >> > Even >> > though we now have ability to mark

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau wrote: > With range partitioning, we guarantee that each partition contains non- > overlapping values. Since we know the range allowed for each partition, it is > possible to sort them according to the partition key (as is done already for > looking u

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Mon, Mar 20, 2017 at 8:11 PM, Robert Haas wrote: > On Sun, Mar 19, 2017 at 3:05 AM, Pavan Deolasee > wrote: > > On Thu, Mar 16, 2017 at 12:53 PM, Robert Haas > wrote: > > >> > >> /me scratches head. > >> > >> Aren't pre-warm and post-warm just (better) names for blue and red? > >> > > > > Ye

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Andres Freund writes: > On 2017-03-20 10:35:15 -0400, Stephen Frost wrote: >> I continue to be of the opinion that this entire discussion is quite >> flipped from how we really should be running things- adding regression >> tests to improve code coverage, particularly when they're simply adding >>

Re: [HACKERS] Re: [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > New tests are not zero-cost; they create a distributed burden on the > buildfarm and, by increasing the buildfarm cycle time, slow down feedback > to authors of subsequent patches. So I'm very much not on board with > any argument that "more tests are

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Mar 15, 2017 at 12:46 AM, Alvaro Herrera wrote: > Pavan Deolasee wrote: > > On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > I have already commented about the executor involvement in btrecheck(); > > > that doesn't seem good. I previously

Re: [HACKERS] [Proposal] Make the optimiser aware of partitions ordering

On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote: > On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau wrote: > > With range partitioning, we guarantee that each partition contains non- > > overlapping values. Since we know the range allowed for each partition, it > > is possible to sort them acc

Re: [HACKERS] PinBuffer() no longer makes use of strategy

if (buf->usage_count < BM_MAX_USAGE_COUNT) if (BUF_STATE_GET_USAGECOUNT(buf_state) != BM_MAX_USAGE_COUNT) being prone to paranoia, I prefer the first, but I've seen both styles in the code so I don't know if it's worth futzing with. Ok, let's be paranoic and do this same way

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera wrote: > > @@ -234,6 +236,21 @@ index_beginscan(Relation heapRelation, > > scan->heapRelation = heapRelation; > > scan->xs_snapshot = snapshot; > > > > + /* > > + * If the index supports recheck, make sure that index tuple is >

Re: [HACKERS] PinBuffer() no longer makes use of strategy

On Mon, Mar 20, 2017 at 6:09 PM, Teodor Sigaev wrote: > if (buf->usage_count < BM_MAX_USAGE_COUNT) >> if (BUF_STATE_GET_USAGECOUNT(buf_state) != BM_MAX_USAGE_COUNT) >> >> being prone to paranoia, I prefer the first, but I've seen both >> styles in >> the code so I don't know i

Re: [HACKERS] Our feature change policy

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Sun, Mar 19, 2017 at 04:15:09PM -0400, Tom Lane wrote: > > Stephen Frost writes: > > > If we take your approach to its logical conclusion then we should be > > > planning to maintain all user-facing deprecated features for as long as > > > the

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > On 2017-03-15 20:09:03 -0400, Tom Lane wrote: >> I think it would be worth creating a README file giving an overview >> of how all of this patch is supposed to work. You also need to do a >> whole lot more work on the function-level comments. > I tried to improve upon bot

Re: [HACKERS] [POC] A better way to expand hash indexes.

Hi Amit, Thanks for the review, On Mon, Mar 20, 2017 at 5:17 PM, Amit Kapila wrote: > idea could be to make hashm_spares a two-dimensional array > hashm_spares[32][4] where the first dimension will indicate the split > point and second will indicate the sub-split number. I am not sure > whether

Re: [HACKERS] Our feature change policy

Stephen Frost writes: > * Bruce Momjian (br...@momjian.us) wrote: >> 1. make the change now and mention it in the release notes >> 2. #1, but also provide backward compatibility for 5+ years >> 3. mark the feature as deprecated and remove/change it in 5+ years >> 4. #3, but issue a warning for

Re: [HACKERS] Our feature change policy

On Mon, Mar 20, 2017 at 11:40:34AM -0400, Tom Lane wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> 1. make the change now and mention it in the release notes > >> 2. #1, but also provide backward compatibility for 5+ years > >> 3. mark the feature as deprecated

Re: [HACKERS] Our feature change policy

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Bruce Momjian (br...@momjian.us) wrote: > >> 1. make the change now and mention it in the release notes > >> 2. #1, but also provide backward compatibility for 5+ years > >> 3. mark the feature as deprecated and remove/c

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 8:21 AM, Robert Haas wrote: > On Fri, Mar 17, 2017 at 8:10 PM, Robert Haas wrote: >> While I was studying what you did with reparameterize_path_by_child(), >> I started to wonder whether reparameterize_path() doesn't need to >> start handling join paths. I think it only h

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

Pavan Deolasee wrote: > On Tue, Mar 14, 2017 at 7:17 AM, Alvaro Herrera > wrote: > > I didn't like this comment very much. But it's not necessary: you have > > already given relcache responsibility for setting rd_supportswarm. The > > only problem seems to be that you set it in RelationGetIndex

Re: [HACKERS] Partitioned tables and relfilenode

On Fri, Mar 17, 2017 at 4:57 AM, Amit Langote wrote: >> Yes, but on the flip side, you're having to add code in a lot of >> places -- I think I counted 7 -- where you turn around and ignore >> those AppendRelInfos. > > Perhaps you were looking at the previous version with "minimal" appinfos > cont

Re: [HACKERS] Our feature change policy

On Mon, Mar 20, 2017 at 11:57:13AM -0400, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> 1. make the change now and mention it in the release notes > > >> 2. #1, but also provide backward co

Re: [HACKERS] Our feature change policy

On Mon, Mar 20, 2017 at 8:57 AM, Stephen Frost wrote: > Tom, > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > * Bruce Momjian (br...@momjian.us) wrote: > > >> 1. make the change now and mention it in the release notes > > >> 2. #1, but also provide backward compatibil

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 9:44 AM, Ashutosh Bapat wrote: >> I believe it would also be best to include 0011's changes to >> adjust_appendrel_attrs_multilevel in 0001. > > The function needs to repeat the "adjustment" process for every > "other" relation (join or base) that it encounters, by testing

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 9:44 AM, Ashutosh Bapat wrote: > Right. If we could use parent Vars to indicate parent Var or child Var > depending upon the context, a lot of memory issues would be solved; we > wouldn't need to translate a single expression. But I think that's not > straight forward. I ha

Re: [HACKERS] WIP: Faster Expression Processing v4

Andres Freund writes: > Additionally I added a regression test for the nearly entirely untested > nodeTidscan.c, after I'd broken it previously without noticing (thanks > Andreas). I went ahead and pushed this part, since it seemed pretty uncontroversial. I added a bit more stuff to get the LOC m

Re: [HACKERS] Create replication slot in pg_basebackup if requested and not yet present

Hi, On Mon, Mar 20, 2017 at 02:42:32PM +0300, Arthur Zakirov wrote: > Also maybe it would be good if pg_basebackup had a way to drop created slot. > Although "drop slot" is not related with concept of automatically created > slots, it will good if user will have a way to drop slots. If you want t

Re: [HACKERS] Our feature change policy

On Mon, Mar 20, 2017 at 9:18 AM, Bruce Momjian wrote: > . #3 and #4 would need to be weighted depending on > whether choosing them would delay progress, e.g. it did delay progress > on standard-conforming strings, but the delay was determined to be > reasonable. > w.r.t. standard-conforming str

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 12:07 PM, Rafia Sabih wrote: > On a further testing of this patch I find another case when it is > showing regression, the time taken with patch is around 160 secs and > without it is 125 secs. This is basically the same problem as before; the partitionwise case is doing t

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/02/17 22:32, Stephen Frost wrote: > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > >> In certain cases, pg_dump's dumpTableSchema() emits a separate ALTER TABLE > >> command for those schema elements of a table that c

[HACKERS] [PATCH] Removes uninitialized variable compiler warning

This patch removes a compiler warning. warning: variable 'lenlemm' is uninitialized when used here [-Wuninitialized] This is my first commit to postgres. I've read through http://wiki.postgresql.org/wiki/Submitting_a_Patch, but I may have missed something. diff --git a/src/backend/tsearch/ts_pa

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Sun, Mar 19, 2017 at 12:15 AM, Pavan Deolasee wrote: >> It seems like an important invariant for WARM is that any duplicate >> index values ought to have different TIDs (actually, it's a bit >> stricter than that, since btrecheck() cares about simple binary >> equality). > > Yes. I think in the

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

> > Hmm. I would kind of like to move the IS_JOIN_REL() and > IS_OTHER_REL() stuff to the front of the series. In other words, I > propose that we add those macros first, each testing for only the one > kind of RelOptInfo that exists today, and change all the code to use > them. Then, when we ad

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

> > On a further testing of this patch I find another case when it is > showing regression, the time taken with patch is around 160 secs and > without it is 125 secs. > Another minor thing to note that is planning time is almost twice with > this patch, though I understand that this is for scenario

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 12:52 PM, Ashutosh Bapat wrote: >> Hmm. I would kind of like to move the IS_JOIN_REL() and >> IS_OTHER_REL() stuff to the front of the series. In other words, I >> propose that we add those macros first, each testing for only the one >> kind of RelOptInfo that exists toda

Re: [HACKERS] [PATCH] Removes uninitialized variable compiler warning

Todd Sedano writes: > This patch removes a compiler warning. > warning: variable 'lenlemm' is uninitialized when used here > [-Wuninitialized] Hm, on what compiler? AFAICS, that parsetext() function hasn't changed meaningfully since 2007, and nobody complained of uninitialized-variable warnings

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 10:26 PM, Robert Haas wrote: > On Mon, Mar 20, 2017 at 12:52 PM, Ashutosh Bapat > wrote: >>> Hmm. I would kind of like to move the IS_JOIN_REL() and >>> IS_OTHER_REL() stuff to the front of the series. In other words, I >>> propose that we add those macros first, each te

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 20, 2017 at 1:19 PM, Ashutosh Bapat wrote: >> That seems different than what I suggested and I'm not sure what the >> reason is for the difference? > > The patch adding macros IS_JOIN_REL() and IS_OTHER_REL() and changing > the code to use it will look quite odd by itself. We are not c

Re: [HACKERS] increasing the default WAL segment size

Hello, PFA the updated patch. On Fri, Mar 17, 2017 at 6:40 AM, Robert Haas wrote: > On Tue, Mar 14, 2017 at 1:44 AM, Beena Emerson > wrote: > > Attached is the updated patch. It fixes the issues and also updates few > code > > comments. > > I did an initial readthrough of this patch tonight ju

Re: [HACKERS] logical replication access control patches

On 20/03/17 13:32, Peter Eisentraut wrote: > On 3/18/17 09:31, Petr Jelinek wrote: >>> 0003 Add USAGE privilege for publications >>> >>> a way to control who can subscribe to a publication >>> >> Hmm IIUC this removes ability of REPLICATION role to subscribe to >> publications. I am not quite sure

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander wrote: > createdb, dropdb - also not clear they're about postgres, more likely to be > used by mistake but not that bad. That said, do they add any *value* beyond > what you can do with psql -c "CREATE DATABASE"? I don't really see one, so > I'd sug

Re: [HACKERS] Removing binaries (was: createlang/droplang deprecated)

On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote: > On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander wrote: > > createdb, dropdb - also not clear they're about postgres, more likely to > > be > > used by mistake but not that bad. That said, do they add any *value* > > beyond > > what yo

Re: [HACKERS] Microvacuum support for Hash Index

On Sat, Mar 18, 2017 at 4:35 AM, Amit Kapila wrote: > This version looks good to me. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscriptio

Re: [HACKERS] WIP: Faster Expression Processing v4

... is there a reason why resultnum for EEOP_ASSIGN_* steps is declared size_t and not just int? Since it's an array index, and one that certainly can't be bigger than AttrNumber, that seems rather confusing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] Logical replication existing data copy

The current patch causes a failure in the pg_dump tests, because the generated CREATE SUBSCRIPTION commands make connection attempts that don't work. We have the pg_dump option --no-create-subscription-slots for this, but I suppose we should expand that to --no-subscription-connect and use the new

Re: [HACKERS] Logical replication existing data copy

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > The current patch causes a failure in the pg_dump tests, because the > generated CREATE SUBSCRIPTION commands make connection attempts that > don't work. We have the pg_dump option --no-create-subscription-slots > for this, but

Re: [HACKERS] patch proposal

Hi Venkata, On 2/28/17 11:59 PM, Venkata B Nagothi wrote: On Wed, Mar 1, 2017 at 1:14 AM, Venkata B Nagothi mailto:nag1...@gmail.com>> wrote: On Tue, Jan 31, 2017 at 6:49 AM, David Steele mailto:da...@pgmasters.net>> wrote: Do you know when those will be ready? Attached are bot

Re: [HACKERS] Inadequate traces in TAP tests

On 03/20/2017 10:25 AM, Craig Ringer wrote: > > > I'd like to enable Carp's features to use confess for traces, and > switch all use of die to that. We could learn a lot about > unplanned-for test failures where a test script dies rather than > failing a test if we used carp effectively. > > >

Re: [HACKERS] Inadequate traces in TAP tests

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 03/20/2017 10:25 AM, Craig Ringer wrote: > > I'd like to enable Carp's features to use confess for traces, and > > switch all use of die to that. We could learn a lot about > > unplanned-for test failures where a test script die

Re: [HACKERS] Removing binaries

On 3/20/17 3:40 PM, Jan de Visser wrote: On Monday, March 20, 2017 3:30:49 PM EDT Robert Haas wrote: On Sat, Mar 18, 2017 at 4:12 PM, Magnus Hagander wrote: createdb, dropdb - also not clear they're about postgres, more likely to be used by mistake but not that bad. That said, do they add any

Re: [HACKERS] extended statistics: n-distinct

Alvaro Herrera wrote: > * I'm not terribly happy with the header organization. I think > VacAttrStats should be in its own (new) src/include/statistics/analyze.h > for example (which cleans up a bunch of existing stuff a bit) I tried this and it doesn't actually do any good. Patch attached, whi

  1   2   >