Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

2017-06-16 Thread Kevin Grittner
s that were run during the first try. For examples, to help get a feel of why that is, see: https://wiki.postgresql.org/wiki/SSI -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to y

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

2017-06-15 Thread Kevin Grittner
On Thu, Jun 15, 2017 at 4:18 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Kevin Grittner wrote: > As far as I understand her proposal, it is exactly the opposite -- if a > transaction fails, it is discarded. And this P.S. note is asking > whether this is a good idea,

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

2017-06-15 Thread Kevin Grittner
*new* set of transactions. Essentially, the transaction should only count toward the TPS rate when it eventually completes without a serialization failure. Marina, did I understand you correctly? -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers ma

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

2017-06-13 Thread Kevin Grittner
the index AMs. https://www.postgresql.org/docs/9.6/static/regress-coverage.html -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-07 Thread Kevin Grittner
or each clause within a statement -- well, it won't be a problem for matview maintenance. The biggest hurt there would be to *my* sense of aesthetics. ;-) -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-07 Thread Kevin Grittner
ng the old table, but if the algorithm treats all > tuples in the old table as deletes (even though in this case they > result from updates) and all tuples in the new table as inserts (even > though in this case *some* of them result from updates) anyway then I > don't think it m

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-07 Thread Kevin Grittner
ssues that the resources required to support what I do is not beyond what I can deliver. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-07 Thread Kevin Grittner
uot;old" table for any rows affected by a delete or update and a "new" table for any rows affected by an update or delete. If we have a single statement that combines INSERT and UPDATE behaviors, it might make sense to have an "old" table for updates and a single "new

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-06-07 Thread Kevin Grittner
? Two SSI functions stand out: 10.86% PredicateLockTuple 3.51% CheckForSerializableConflictIn In both cases, most of that seems to go to lightweight locking. Since you said this is a CPU graph, that again suggests spinlock contention issues. -- Kevin Grittner VMware vCenter Server https://w

Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index

2017-06-06 Thread Kevin Grittner
a frequent situation, but still. Should we skip > finishing split or should we add it to collision check too? When a page is split, I think you need to call PredicateLockPageSplit() before it gets to the point that an insert to get to it. -- Kevin Grittner VMware vCenter Server https://www.vmware.c

[HACKERS] Re: GSoC 2017 weekly progress reports ("Explicitly support predicate locks in index access methods besides b-tree")

2017-06-06 Thread Kevin Grittner
ns (PredicateLockPage(), CheckForSerializableConflictIn() ...etc) When you have a patch for any AM, please post it to the list. Each AM will be reviewed and considered for commit separately. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-h

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-06 Thread Kevin Grittner
On Tue, Jun 6, 2017 at 3:41 PM, Marko Tiikkaja <ma...@joh.to> wrote: > On Tue, Jun 6, 2017 at 10:25 PM, Kevin Grittner <kgri...@gmail.com> wrote: >> It took years to get an in-depth review, then I was asked >> not to commit it because others were working on pat

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-06 Thread Kevin Grittner
it a few days for objections before reverting. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-03 Thread Kevin Grittner
able usage until we sort out the basics of triggers firing from CTE DML in the first place. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-06-03 Thread Kevin Grittner
see a way to attack the other 90% (or some portion of it larger than 10%) instead, I think we could adjust the scope based on those results. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-06-02 Thread Kevin Grittner
an the actual walking and manipulation of the list itself. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index

2017-05-31 Thread Kevin Grittner
to all new pages generated after a successful split > operation. For that, we can insert a call for PredicateLockPageSplit() in > gistplacetopage(). That all sounds good. When you code a patch, don't forget to add tests to src/test/isolation. Do you need any help getting a development/build/test env

[HACKERS] Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-31 Thread Kevin Grittner
On Wed, May 31, 2017 at 1:44 AM, Noah Misch <n...@leadboat.com> wrote: > IMMEDIATE ATTENTION REQUIRED. I should be able to complete review and testing by Friday. If there are problems I might not take action until Monday; otherwise I should be able to do so on Friday. -- Kevin Grittn

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-18 Thread Kevin Grittner
ongly feel that must be reflected in the transition table. This needs to be fixed. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-16 Thread Kevin Grittner
On Tue, May 16, 2017 at 4:50 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> On Wed, May 10, 2017 at 7:02 AM, Thomas Munro >> <thomas.mu...@enterprisedb.com> wrote: >>>

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-16 Thread Kevin Grittner
add transition tables changed caching of a trigger function to key on the combination of the function and the target relation, rather than having one cache entry regardless of the target table. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-15 Thread Kevin Grittner
ideal would be that we support an ONLY option for trigger declaration. If your statement is ONLY on the a given level in the hierarchy, the row triggers for only that level would fire. If you don't use ONLY, a row trigger at that level would fire for operations at that level or any child level, but with a

Re: [HACKERS] How huge does mvtest_huge need to be?

2017-05-03 Thread Kevin Grittner
On Wed, May 3, 2017 at 4:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > At this point I'm inclined to just delete the whole test. ok -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make change

Re: [HACKERS] How huge does mvtest_huge need to be?

2017-05-03 Thread Kevin Grittner
quot; in the object names then seems odd, of course. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Transition tables for triggers on foreign tables and views

2017-05-02 Thread Kevin Grittner
similar odd behavior under inheritance. I hope to post something Friday. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-01 Thread Kevin Grittner
On Mon, May 1, 2017 at 11:53 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner <kgri...@gmail.com> wrote: >> On Mon, May 1, 2017 at 10:01 AM, Robert Haas <robertmh...@gmail.com> wrote: >>> It seems pretty clear to m

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

2017-05-01 Thread Kevin Grittner
ate, discuss and produce a patch. I think best case is Friday. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Transition tables for triggers on foreign tables and views

2017-04-28 Thread Kevin Grittner
On Fri, Apr 28, 2017 at 3:54 PM, Kevin Grittner <kgri...@gmail.com> wrote: > Not firing a table's DML because it was fired off a view would be crazy, should read: Not firing a table's trigger because the trigger is on DML run from a view's INSTEAD OF trigger would be crazy, -- Kevin

Re: [HACKERS] Transition tables for triggers on foreign tables and views

2017-04-28 Thread Kevin Grittner
On Fri, Apr 28, 2017 at 2:42 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@gmail.com> writes: >> On Tue, Apr 25, 2017 at 6:17 PM, Thomas Munro >> <thomas.mu...@enterprisedb.com> wrote: >>> For views, aside from the question of trans

Re: [HACKERS] Transition tables for triggers on foreign tables and views

2017-04-28 Thread Kevin Grittner
or attempt to do otherwise, or is there something to salvage that has worked at some point? If we do get these working, don't they deserve at least one regression test? Will post again after I have a chance to review the FDW issue. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

2017-04-17 Thread Kevin Grittner
arting with the list Craig included) as section headers, and put links to useful reading below each? -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] recent deadlock regression test failures

2017-04-10 Thread Kevin Grittner
On Mon, Apr 10, 2017 at 1:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Kevin Grittner <kgri...@gmail.com> writes: >> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I notice that the safe-snapshot code path is not paying attention

Re: [HACKERS] recent deadlock regression test failures

2017-04-10 Thread Kevin Grittner
hot processing needs to do anything special if the above rules are followed, nor can I see anything special it *could* do. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] recent deadlock regression test failures

2017-04-08 Thread Kevin Grittner
heck for matches in its array > argument directly; it could probably do that significantly faster than the > general-purpose array && code. So we'd have to expend a bit of backend C > code, but we'd have something that would be quite speedy and we could > customize in fut

Re: [HACKERS] recent deadlock regression test failures

2017-04-07 Thread Kevin Grittner
; and that 'inLink' is the correct link to be following? If you're starting from the blocked (read-only) transaction (which you are), inLink is the one to follow. Note: It would be better form to use the SxactIsDeferrableWaiting() macro than repeat the bit-testing code directly in your function.

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2017-04-07 Thread Kevin Grittner
On Mon, Feb 27, 2017 at 7:35 AM, Dagfinn Ilmari Mannsåker <ilm...@ilmari.org> wrote: > Kevin Grittner <kgri...@gmail.com> writes: > >> It occurred to me that it would make sense to allow these settings >> to be attached to a database or table (though *not* a role). I

Re: [HACKERS] recent deadlock regression test failures

2017-04-07 Thread Kevin Grittner
On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund <and...@anarazel.de> wrote: >> >>> I'd r

Re: [HACKERS] Remaining 2017-03 CF entries

2017-04-07 Thread Kevin Grittner
evin, should be easy enough I was planning on pushing this today. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] recent deadlock regression test failures

2017-04-07 Thread Kevin Grittner
On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund <and...@anarazel.de> wrote: > I'd rather fix the issue, than remove the tests entirely. Seems quite > possible to handle blocking on Safesnapshot in a similar manner as > pg_blocking_pids? I'll see what I can figure out. --

Re: [HACKERS] recent deadlock regression test failures

2017-04-07 Thread Kevin Grittner
ZABLE READ ONLY DEFERRABLE code, but it's probably not worth adding 4 hours to any tests, even if it only shows up with CLOBBER_CACHE_ONLY. I assume the consensus is that I should revert it? -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [GSoC] Push-based query executor discussion

2017-04-06 Thread Kevin Grittner
Sorry, I didn't notice that this was going to a public list. That URL is only available to people who signed up as mentors for PostgreSQL GSoC participation this year. Does the link to the draft work for you? -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] [GSoC] Push-based query executor discussion

2017-04-06 Thread Kevin Grittner
mprovements. Note that the final proposal is here: https://summerofcode.withgoogle.com/serve/5874530240167936/ Also, I just entered a comment about an important question that I think needs to be answered right up front. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postg

Re: [HACKERS] delta relations in AFTER triggers

2017-04-04 Thread Kevin Grittner
On Mon, Apr 3, 2017 at 7:16 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Thomas Munro &l

Re: [HACKERS] SERIALIZABLE with parallel query

2017-04-03 Thread Kevin Grittner
blems that we had missed. Perhaps they can describe their testing or make other suggestions. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

2017-04-03 Thread Kevin Grittner
com https://www.postgresql.org/message-id/CAD=a8sbzwgd4u-tasjp0owtpileffhoz5o5ev0um6digqbv...@mail.gmail.com Unless you can produce convincing proof to the contrary, your proposal will be disqualified because of plagiarism. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@

Re: [HACKERS] delta relations in AFTER triggers

2017-04-03 Thread Kevin Grittner
it to spi.c or creating a new file -- or just duplicating these 30-some lines of code to every PL. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

2017-04-01 Thread Kevin Grittner
cking > exists in the btree AM, where it required the addition of 17 function calls > to implement, but remains unimplemented in the gin, gist, spgist, brin, and > hash index AMs. So we nned to insert function calls at other places also. Exactly. > Also tell me can we evaluate the p

Re: [HACKERS] delta relations in AFTER triggers

2017-03-31 Thread Kevin Grittner
alized that way, not as Enr) in related >> function names, where that seemed sensible. I really do *not* like >> "Enr" as a global name. > > Yeah, I had the same thought about capitalization but wasn't sure if > it was worth suggesting. But since Tom did, +1 from me. Will do

Re: [HACKERS] delta relations in AFTER triggers

2017-03-31 Thread Kevin Grittner
On Thu, Mar 30, 2017 at 11:51 AM, Kevin Grittner <kgri...@gmail.com> wrote: > New version attached. It needs some of these problem cases added to > the testing, and a mention in the docs that only C and plpgsql > triggers can use the feature so far. I'll add those tomorrow. Do

Re: [HACKERS] delta relations in AFTER triggers

2017-03-31 Thread Kevin Grittner
limits. Any suggestions? -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] delta relations in AFTER triggers

2017-03-30 Thread Kevin Grittner
g similar lines, but had not gotten it working. Merged your version and mine, taking the best of both. :-) Thanks for the reviews and the fixes! New version attached. It needs some of these problem cases added to the testing, and a mention in the docs that only C and plpgsql triggers can use

[HACKERS] Re: [pgsql-students] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

2017-03-30 Thread Kevin Grittner
to someone else) - A description of what they will do, and how - Milestones with dates - What they consider to be the test that they have successfully completed the project -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

[HACKERS] Re: [pgsql-students] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

2017-03-30 Thread Kevin Grittner
tree/nbtsearch.c:1874: PredicateLockPage(rel, BufferGetBlockNumber(buf), scan->xs_snapshot); src/backend/access/nbtree/nbtpage.c:1410: PredicateLockPageCombine(rel, leafblkno, leafrightsib); -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-30 Thread Kevin Grittner
e much I could see doing a prototype without generalization, but you would still have most of the same shared memory issues, since the structure *must* live in shared memory. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: h

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-27 Thread Kevin Grittner
ed. I'm afraid a few new issues came to mind reading it again. (Nothing serious; just some points that could benefit from a little elaboration.) -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-24 Thread Kevin Grittner
don't show up for you or you need clarification. Overall, if the comments are addressed, I think it is great. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Guidelines for GSoC student proposals / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-23 Thread Kevin Grittner
> https://docs.google.com/document/d/17TAs3EJIokwPU7UTUmnlVY3ElB-VHViyX1zkQJmrD1A/edit?usp=sharing > > I was wondering if you have time to review the proposal and give me some > comments? Will take a look and give you an initial review in a day or two. -- Kevin Grittner -- Sent via pgsq

Re: [HACKERS] Candidate for local inline function?

2017-03-17 Thread Kevin Grittner
On Fri, Mar 17, 2017 at 3:23 PM, Andres Freund <and...@anarazel.de> wrote: > On 2017-03-17 15:17:33 -0500, Kevin Grittner wrote: >> Why do we warn of a hazard here instead of eliminating said hazard >> with a static inline function declaration in executor.h? > > Presum

[HACKERS] Candidate for local inline function?

2017-03-17 Thread Kevin Grittner
cts, modern versions of gcc have generated the same code for a macro versus a static inline function, at least in the cases I checked. -- Kevin Grittner

[HACKERS] Guidelines for GSoC student proposals

2017-03-17 Thread Kevin Grittner
I've found various sources that give hints about what a student proposal should look like, but nothing I could just give as a link, so I pulled together what I could find, tempered by my own ideas and opinions. I suggest that we send the below, or something like it to each student who expresses

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-15 Thread Kevin Grittner
ores and almost all of the memory, with heavy contention on shared memory, the situation is very different. Shared resource access time is going to be non-uniform no matter what you do. The difference is that the OS can still make *process local* allocations from nearby memory segments, whil

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-15 Thread Kevin Grittner
On Tue, Mar 14, 2017 at 3:45 PM, Kevin Grittner <kgri...@gmail.com> wrote: >> On 3/14/17 17:34, Mengxing Liu wrote: >>> There are several alternative benchmarks. Tony suggested that we >>> should use TPC-E and TPC-DS. > > More benchmarks is better, all other

Re: [HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-14 Thread Kevin Grittner
h --enable-cassert, you get the best stack traces and you can more easily break down execution profiles. That especially true if you disable optimization and don't omit frame pointers. But all of those things distort the benchmarks -- adding a lot of time, and not necessarily in proportion to where the time goes with an optimized build. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] delta relations in AFTER triggers

2017-03-13 Thread Kevin Grittner
ep in mind that not just anyone can put a trigger on a table. > * In future we could consider teaching it about functional > dependencies as required by the spec; if you can SELECT id, name FROM > GROUP BY id, I believe you should be able to SELECT > id, name FROM GROUP BY id, but currentl

[HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-13 Thread Kevin Grittner
k perhaps the first milestone on the project should be to develop a set of benchmarks we want to compare to at the end. That would need to include a stress test that clearly shows the problem we're trying to solve, along with some cases involving 1 or two connections -- just to make sure we don't harm p

[HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-11 Thread Kevin Grittner
ore cores on 4 or more sockets with a large number of active connections. I don't know whether you have access to a machine capable of putting this kind of stress on it (perhaps at your university?), but if not, the community has access to various resources we should be able to schedule time on. It may

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-10 Thread Kevin Grittner
ing by the PostgreSQL mentors. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSOC Introduction / Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

2017-03-10 Thread Kevin Grittner
itFest in progress; reviewing patches is a good way to become involved and familiar with the community processes. https://wiki.postgresql.org/wiki/CommitFest -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] SQL Standard Feature T211

2017-03-09 Thread Kevin Grittner
r "unsupported" list until those two points are addressed? Does anyone know of anything else that would need to be done? -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] delta relations in AFTER triggers

2017-03-09 Thread Kevin Grittner
On Tue, Mar 7, 2017 at 6:28 PM, Kevin Grittner <kgri...@gmail.com> wrote: > New patch attached. And bit-rotted less than 24 hours later by fcec6caa. New patch attached just to fix bit-rot. That conflicting patch might be a candidate to merge into the new Ephemeral Named Relation provi

Re: [HACKERS] delta relations in AFTER triggers

2017-03-07 Thread Kevin Grittner
ation here? Essentially, because plpgsql does some things through SPI and some things not. Both cases are covered. > On Mon, Dec 19, 2016 at 4:35 AM, Thomas Munro > <thomas.mu...@enterprisedb.com> wrote: >> On Sun, Dec 18, 2016 at 3:15 PM, Kevin Grittner <kgri...@gmai

[HACKERS] WARNING: relcache reference leak: relation "p1" not closed

2017-03-06 Thread Kevin Grittner
: relcache reference leak: relation "p1" not closed VACUUM -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] WARNING: relcache reference leak: relation "p1" not closed

2017-03-06 Thread Kevin Grittner
[original message held up for review -- should be along eventualy...] On Mon, Mar 6, 2017 at 3:11 PM, Kevin Grittner <kgri...@gmail.com> wrote: > With e434ad39ae7316bcf35fd578dd34ad7e1ff3c25f I did a `make world`, > `make install-world`, a fresh default initdb, a start with defa

Re: [HACKERS] delta relations in AFTER triggers

2017-03-02 Thread Kevin Grittner
arserSetupArg=0x7fa58185c2a0, queryEnv=0x7fa581857798) + 128 >> at postgres.c:706 [opt] > > Do you know when you will have a new patch ready? > > This looks like an interesting and important feature but I think it's > going to have to come together quickly if it's going t

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-02-09 Thread Kevin Grittner
t have them available by default. > > As far as the core code is concerned, 3b and 3c are the same thing. I think so, too, if we're talking about an extension in core. My vote is for 3b. If someone wants to write the alias extension and make it available outside of core, fine -- though they

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-02-06 Thread Kevin Grittner
g: Stephen, Vladimir, David S, Michael P (with > aliases for functions, I could live without at this point...) I vote for 3 as well, with 1 as the only sane alternative. -- Kevin Grittner -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-02-03 Thread Kevin Grittner
s seem unimportant, I think finishing the job is better. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2017-01-23 Thread Kevin Grittner
cate_locks_per_transaction / -max_predicate_locks_per_relation. > Making the default value -2 keeps backwards compatibility. > > Alternatively we could have a separate setting for the fraction (which > could then be a floating-point number, for finer control), and use the > absolute val

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2017-01-23 Thread Kevin Grittner
On Mon, Jan 23, 2017 at 9:50 AM, Dagfinn Ilmari Mannsåker <ilm...@ilmari.org> wrote: > Kevin Grittner <kgri...@gmail.com> writes: > >> (1) The new GUCs are named max_pred_locks_per_*, but the >> implementation passes them unmodified from a function specifying at

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2017-01-20 Thread Kevin Grittner
effective_cache_size. Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2017-01-20 Thread Kevin Grittner
m on vacation next week, so I would not do so before then; in fact I may not have a chance to respond to any comments before then. If the author wishes to make these changes, great; otherwise I can do it before commit. I will mark this Ready for Committer. -- Kevin Grittner EDB: http://www.enterprisedb.com The En

Re: [HACKERS] delta relations in AFTER triggers

2017-01-20 Thread Kevin Grittner
On Fri, Jan 20, 2017 at 2:08 PM, Nico Williams <n...@cryptonector.com> wrote: > On Fri, Jan 20, 2017 at 01:37:33PM -0600, Kevin Grittner wrote: >> There is currently plenty of room for pseudo-MV implementations, >> and may be for a while. It's a good indication of the ne

Re: [HACKERS] delta relations in AFTER triggers

2017-01-20 Thread Kevin Grittner
er order" SQL > features that make this sort of thing easier. In particular, here, row > values and record types, and being able to refer to a table as a column > of the table's record type. Yeah, I found that quite handy in developing the REFRESH feature, and expect to be using i

Re: [HACKERS] delta relations in AFTER triggers

2017-01-20 Thread Kevin Grittner
Attached is v10 which fixes bitrot from v9 caused by ea15e186. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v10.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] delta relations in AFTER triggers

2017-01-19 Thread Kevin Grittner
Attached is v9 which fixes bitrot from v8. No other changes. Still needs review. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v9.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Packages: Again

2017-01-13 Thread Kevin Grittner
ternational SQL standard documents. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Patch to implement pg_current_logfile() function

2017-01-13 Thread Kevin Grittner
of the backup do not present a similar hazard. So while I agree that there is no harm in including current_logfiles in base backups, I object to the comparisons to the more dangerous files. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal

2017-01-12 Thread Kevin Grittner
as someone cares enough to maintain it. I guess that makes my vote -1 on aliases by the project. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [DOCS] [HACKERS] Questionable tag usage

2017-01-10 Thread Kevin Grittner
ing the new default) I might question whether the benefit was worth the effort of adding it. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:/

Re: [HACKERS] RustgreSQL

2017-01-10 Thread Kevin Grittner
performance boost which would not be available if they were instead converted to another language. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscript

Re: [HACKERS] Odd behavior with PG_TRY

2017-01-06 Thread Kevin Grittner
Is there some reason this variable is immune to the problem? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] guc-ify the formerly hard-coded MAX_SEND_SIZE to max_wal_send

2017-01-06 Thread Kevin Grittner
lean, at 80ms RTT > there was a 2x improvement in performance. Is there compression and/or encryption being performed by the network layers? My experience with both is that they run faster on bigger chunks of data, and that might happen before the data is broken into packets. -- Kevin Grittner

Re: [HACKERS] delta relations in AFTER triggers

2016-12-17 Thread Kevin Grittner
ch suggested change (e.g., the inclusion of the query environment in the parameter list of a few more functions). Changed to "Needs review" status. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company transition-v8.diff.gz Description: GNU Zip compre

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-16 Thread Kevin Grittner
read-only transactions. It is still worthwhile to explicitly set serializable transactions to read-only whenever possible, for performance reasons. The idea that a serialization failure is not possible on the first (or only) statement o a read-only transaction was in error, and should be disregarded.

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-16 Thread Kevin Grittner
On Fri, Dec 16, 2016 at 8:24 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Dec 15, 2016 at 9:01 AM, Kevin Grittner <kgri...@gmail.com> wrote: >> I also realized some other properties of read-only transactions >> that might interest you (and that I should p

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-15 Thread Kevin Grittner
possible if the read-only transaction had multiple statements; but the fact that such long saturation runs with SLRU summarization showed no errors on read-only transactions supports the idea that such summarization doesn't compromise that guarantee. Unfortunately, it falls short of proof. :-(

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-15 Thread Kevin Grittner
urity vulnerabilities, in order to make it as safe as possible for people to apply minor releases without fear of breaking something that works, I think we could consider an argument for back-patching a doc change that clarifies or fills omissions that make it difficult to use a feature c

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-14 Thread Kevin Grittner
On Wed, Dec 14, 2016 at 11:12 AM, Ian Jackson <ian.jack...@eu.citrix.com> wrote: > Kevin Grittner writes ("Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: > Retry on constraint violation [and 2 more messages] [and 1 more messages]"): >> On Wed, Dec 14, 2016 at 10:

Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraint violation [and 2 more messages] [and 1 more messages]

2016-12-14 Thread Kevin Grittner
under any circumstances be allowed to commit. If you find any exception to that, please report it as a bug. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] Add GUCs for predicate lock promotion thresholds

2016-12-14 Thread Kevin Grittner
On Wed, Dec 14, 2016 at 8:16 AM, Dagfinn Ilmari Mannsåker <ilm...@ilmari.org> wrote: > Attached is a patch Please add this to the open CommitFest to ensure that it is reviewed. http://commitfest.postgresql.org/action/commitfest_view/open -- Kevin Grittner EDB: http://www.enterpr

  1   2   3   4   5   6   7   8   9   10   >