Re: [HACKERS] Partitioning vs ON CONFLICT

On Fri, Mar 31, 2017 at 11:44 PM, Robert Haas wrote: > On Fri, Mar 31, 2017 at 5:33 PM, Peter Geoghegan wrote: >> In my opinion, for the very limited ON CONFLICT DO NOTHING + no >> inference specification case, the implementation should not care about >> the

Re: [HACKERS] pgbench throttling latency limit

Hi Fabien, On Sun, Aug 24, 2014 at 9:16 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Find attached a new version: - fix dropped percent computation in the final report - simplify progress report code I have reviewed this patch. Is the patch in a patch format which has context? Yes. Does

Re: [HACKERS] pgbench throttling latency limit

Hi Fabien, On Tue, Aug 26, 2014 at 04:07 AM, Fabien COELHO coe...@cri.ensmp.fr wrote: Please find attached a new version which fixes these two points. Indeed it does. Marking the patch ready for a committer. Thanks, ♜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

[HACKERS] LIMIT for UPDATE and DELETE

Greetings, Based on the feedback on my previous patch, I've separated only the LIMIT part into its own feature. This version plays nicely with inheritance. The intended use is splitting up big UPDATEs and DELETEs into batches more easily and efficiently. ♜ *** a/doc/src/sgml/ref/delete.sgml

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Tue, Jun 24, 2014 at 04:08 AM, Heikki Linnakangas hlinnakan...@vmware.com wrote: IMHO this needs to work with inheritance if we are to accept it. It would be a rather strange limitation for no apparent reason, other than that we didn't bother to implement it. It doesn't seem very difficult

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Sun, May 11, 2014 at 4:47 PM, Tom Lane t...@sss.pgh.pa.us wrote: The $64 question is whether we'd accept an implementation that fails if the target table has children (ie, is partitioned). That seems to me to not be up to the project's usual quality expectations, but maybe if there's

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Sun, May 11, 2014 at 10:33 AM, Simon Riggs si...@2ndquadrant.com wrote: On 11 May 2014 07:37, Amit Kapila amit.kapil...@gmail.com wrote: Tom Lane has explained these problems in a very clear manner in his below mail and shared his opinion about this feature as well.

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

Hi, Here's an updated patch.  I had to push the LIMIT processing into ModifyTable to make the behaviour sane in parallel scenarios.  As usual, please ignore if you're busy with 9.4.  I will work on better docs and more tests from now on and am preparing to make a solid case for adding this.

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

Oops.  Of course shouldn't try and change how INSERT works.  Latest version attached. ♜ update_delete_order_by_limit_v2.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

[HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

Hello hackers, I know you're busy wrapping up the 9.4 release, so please ignore this patch. ♜ update_delete_order_by_limit_v0.diff Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] 9.5: UPDATE/DELETE .. ORDER BY .. LIMIT ..

On Saturday, February 22, 2014 11:57:06 PM, Peter Geoghegan p...@heroku.com wrote: I think you should describe what the patch does, why you believe the feature is necessary, and perhaps how it compares to other, similar things. You have documentation changes here, but that doesn't really tell us