Corey Huinker writes:
>> I've also used the technique quite a lot, but only using the PK,
>> didn't know about the ctid trick, so many thanks for documenting it.
> tid-scans only became a thing a few versions ago (12?). Prior to that, PK
> was the only way to go.
I think we had TID scans for
>
> > As for whether it's commonplace, when I was a consultant I had a number
> > of customers that I had who bemoaned how large updates caused big
> > replica lag, basically punishing access to records they did care about
> > in order to properly archive or backfill records they don't care about.
On Tue, Feb 13, 2024, at 23:56, Corey Huinker wrote:
> This patch came out of a discussion at the last PgCon with the person
> who made the "fringe feature" quote, who seemed quite supportive of
> documenting the technique. The comment may have been in regards to
> actually implementing a LIMIT
On Tue, Feb 13, 2024 at 11:51 AM Joel Jacobson wrote:
> On Tue, Feb 13, 2024, at 10:28, Laurenz Albe wrote:
> > On Mon, 2024-02-12 at 12:24 -0500, Corey Huinker wrote:
> >> > Do you plan to add it to the commitfest? If yes, I'd set it "ready
> for committer".
> >>
> >> Commitfest entry
On Tue, Feb 13, 2024, at 10:28, Laurenz Albe wrote:
> On Mon, 2024-02-12 at 12:24 -0500, Corey Huinker wrote:
>> > Do you plan to add it to the commitfest? If yes, I'd set it "ready for
>> > committer".
>>
>> Commitfest entry reanimated.
>
> Truly... you created a revenant in the already
On Mon, 2024-02-12 at 12:24 -0500, Corey Huinker wrote:
> > Do you plan to add it to the commitfest? If yes, I'd set it "ready for
> > committer".
>
> Commitfest entry reanimated.
Truly... you created a revenant in the already closed commitfest.
I closed that again and added a new entry in
>
> Do you plan to add it to the commitfest? If yes, I'd set it "ready for
> committer".
>
> Commitfest entry reanimated.
On Mon, 2024-02-12 at 11:45 -0500, Corey Huinker wrote:
>
> > - I am not sure if it is necessary to have the at all.
> > I'd say that it is just a trivial variation of the UPDATE example.
> > On the other hand, a beginner might find the example useful.
> > Not sure.
>
> I think a beginner
>
>
> - About the style: there is usually an empty line between an ending
> and the next starting . It does not matter for correctness, but I
> think it makes the source easier to read.
>
Done. I've seen them with spaces and without, and have no preference.
>
> - I would rather have only
On Sat, 2024-02-03 at 15:27 -0500, Corey Huinker wrote:
>
> Here's another attempt, applying Laurenz's feedback:
I like this patch much better.
Some comments:
> --- a/doc/src/sgml/ref/delete.sgml
> +++ b/doc/src/sgml/ref/delete.sgml
> @@ -234,6 +234,24 @@ DELETE FROM films
> In some cases
>
> I have changed the status of commitfest entry to "Returned with
> Feedback" as Laurenz's comments have not yet been resolved. Please
> handle the comments and update the commitfest entry accordingly.
>
>
Here's another attempt, applying Laurenz's feedback:
I removed all changes to the SELECT
On Tue, 31 Oct 2023 at 23:42, Corey Huinker wrote:
>>
>>
>> I think the SQL statements should end with semicolons. Our SQL examples
>> are usually written like that.
>
>
> ok
>
>
>>
>>
>> Our general style with CTEs seems to be (according to
>>
On Tue, 2023-10-31 at 14:12 -0400, Corey Huinker wrote:
>
>
> > About the SELECT example:
> > -
> >
> > That example belongs to UPDATE, I'd say, because that is the main
> > operation.
>
> I'm iffy on that suggestion. A big part of putting it in SELECT was the fact
>
>
>
> I think the SQL statements should end with semicolons. Our SQL examples
> are usually written like that.
>
ok
>
> Our general style with CTEs seems to be (according to
> https://www.postgresql.org/docs/current/queries-with.html):
>
> WITH quaxi AS (
> SELECT ...
> )
> SELECT
On Wed, 2023-06-28 at 14:20 -0400, Corey Huinker wrote:
> This patch adds a few examples to demonstrate the following:
>
> * The existence of the ctid column on every table
> * The utility of ctds in self joins
> * A practical usage of SKIP LOCKED
I had a look at your patch, and I am in favor of
Hi.
-
In cases where a DML operation involving many rows must be performed,
and that table experiences numerous other simultaneous DML operations,
a FOR UPDATE clause used in conjunction with SKIP LOCKED can be useful
for performing partial DML operations:
On Wed, Jun 28, 2023 at 2:20 PM Corey Huinker
wrote:
> This patch adds a few examples to demonstrate the following:
>
Bumping so CF app can see thread.
>
This patch adds a few examples to demonstrate the following:
* The existence of the ctid column on every table
* The utility of ctds in self joins
* A practical usage of SKIP LOCKED
The reasoning for this is a bit long, but if you're interested, keep
reading.
In the past, there has been a
18 matches
Mail list logo
