Sorry, I've just noticed that the letter is shown incorrectly. I rewrote
it below.
As I understand it, you talked about speeding up SeqScan by faster
re-searching through the use of a hash table. At the same time, we have
to build it before that, when there was the initial lookup tuples, right
Hi! Unfortunately,Iwas notableto fullyunderstandyourmessage.Couldyou
explainit to meplease?
On 09.04.2024 16:20, Andrei Lepikhov wrote:
Moreover, it helps even SeqScan: attempting to find a value in the
hashed array is much faster than cycling a long-expression on each
incoming tuple.
AsIu
On Tue, Apr 16, 2024 at 7:20 PM Jeff Davis wrote:
> We maintain the invariant:
>
>XLogCtl->logFlushResult <= XLogCtl->logWriteResult
>
> and the non-shared version:
>
>LogwrtResult.Flush <= LogwrtResult.Write
>
> and that the requests don't fall behind the results:
I had missed the fact t
On Mon, 2024-04-08 at 15:47 -0400, Robert Haas wrote:
> - I couldn't understand why the "Operate
> XLogCtl->log{Write,Flush}Result with atomics" code was correct when I
> read it.
I reviewed ee1cbe806d. It followed a good process of discussion and
review. It was a bit close to the feature freeze f
Hi,
On Saturday, April 13th, 2024 at 12:18 PM, Tomas Vondra wrote:
> On 4/13/24 01:03, David Steele wrote:
> > On 4/12/24 22:12, Tomas Vondra wrote:
> > > On 4/11/24 23:48, David Steele wrote:
> > > > On 4/11/24 20:26, Tomas Vondra wrote:
> > > >
> > > > > FWIW that discussion also mentions stuff
On 4/13/24 21:02, Tomas Vondra wrote:
On 4/13/24 01:23, David Steele wrote:
Even for the summarizer, though, I do worry about the complexity of
maintaining it over time. It seems like it would be very easy to
introduce a bug and have it go unnoticed until it causes problems in the
field. A lot
On 4/13/24 01:23, David Steele wrote:
> On 4/12/24 22:27, Tomas Vondra wrote:
>>
>>
>> On 4/12/24 08:42, David Steele wrote:
>>> On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
> On 4/11/24 10:23, Tom Kincaid wrote:
>>
>> The extensive Beta process we
On 4/13/24 01:03, David Steele wrote:
> On 4/12/24 22:12, Tomas Vondra wrote:
>> On 4/11/24 23:48, David Steele wrote:
>>> On 4/11/24 20:26, Tomas Vondra wrote:
>>>
FWIW that discussion also mentions stuff that I think the feature
should
not do. In particular, I don't think the am
On 4/12/24 22:27, Tomas Vondra wrote:
On 4/12/24 08:42, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has exte
On 4/12/24 22:12, Tomas Vondra wrote:
On 4/11/24 23:48, David Steele wrote:
On 4/11/24 20:26, Tomas Vondra wrote:
>>
FWIW that discussion also mentions stuff that I think the feature should
not do. In particular, I don't think the ambition was (or should be) to
make pg_basebackup into a stand-
On Wed, Apr 10, 2024 at 5:27 PM Robert Haas wrote:
>
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR clause
On 4/12/24 08:42, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and cur
On 4/11/24 23:48, David Steele wrote:
> On 4/11/24 20:26, Tomas Vondra wrote:
>>
>> On 4/11/24 03:52, David Steele wrote:
>>> On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I di
On 4/12/24 12:15, Robert Haas wrote:
On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote:
But they'll try because it is a new pg_basebackup feature and they'll
assume it is there to be used. Maybe it would be a good idea to make it
clear in the documentation that significant tooling will be r
On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote:
> But they'll try because it is a new pg_basebackup feature and they'll
> assume it is there to be used. Maybe it would be a good idea to make it
> clear in the documentation that significant tooling will be required to
> make it work.
I don't a
On 4/11/24 20:26, Tomas Vondra wrote:
On 4/11/24 03:52, David Steele wrote:
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I d
Hi!
I also worked with this patch and until your explanation I didn’t fully
understand the reasons why it was wrong to have this implementation when
removing duplicate OR expressions.
Thank you, now I understand it!
I agree with explanation of Andrei Lepikhov regarding the fact that
there w
On 4/11/24 03:52, David Steele wrote:
> On 4/11/24 10:23, Tom Kincaid wrote:
>>
>> The extensive Beta process we have can be used to build confidence we
>> need in a feature that has extensive review and currently has no known
>> issues or outstanding objections.
>
> I did have objections, here
On 4/11/24 10:23, Tom Kincaid wrote:
The extensive Beta process we have can be used to build confidence we
need in a feature that has extensive review and currently has no known
issues or outstanding objections.
I did have objections, here [1] and here [2]. I think the complexity,
space req
>
> > Yeah, that's an excellent practive, but is why I'm less worried for
> > this feature. The docs at [1] caution about "not to remove earlier
> > backups if they might be needed when restoring later incremental
> > backups". Like Alvaro said, should we insist a bit more about the WAL
> > reten
On 4/10/24 09:50, Michael Paquier wrote:
On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote:
Even so, only keeping WAL for the last backup is a dangerous move in any
case. Lots of things can happen to a backup (other than bugs in the
software) so keeping WAL back to the last full (o
On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> I have another one that I'm not terribly happy about:
>
> Author: Alexander Korotkov
> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
>
> Transform OR clauses to ANY expression
I realize that this has been reverted now, but
On Tue, Apr 9, 2024 at 1:59 AM Peter Eisentraut wrote:
> On 09.04.24 00:58, Michael Paquier wrote:
> > That's more linked to the fact that I was going silent without a
> > laptop for a few weeks before the end of the release cycle, and a way
> > to say to not count on me, while I was trying to kee
On Tue, Apr 9, 2024 at 2:47 AM Robert Haas wrote:
>
> - I'm slightly worried about the TID store work (ee1b30f12, 30e144287,
> 667e65aac35), perhaps for no reason. Actually, the results seem really
> impressive,
First, thanks for the complement. I actually suspect if we had this
years ago, it mig
On Wed, Apr 10, 2024 at 09:29:38AM +1000, David Steele wrote:
> Even so, only keeping WAL for the last backup is a dangerous move in any
> case. Lots of things can happen to a backup (other than bugs in the
> software) so keeping WAL back to the last full (or for all backups) is
> always an excelle
On 4/10/24 01:59, Andrey M. Borodin wrote:
On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
Maybe we should explicitly advise users to not delete that WAL from
their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Post
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
>> What exactly is the point of having a NodeTag in the struct though?
>> If you don't need it to be a valid Node, that seems pointless and
>> confusing. We certainly have plenty of other lists that contain
>> plain str
On Tue, Apr 9, 2024 at 11:42 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> >> Yeah, that's one of the reasons I'm dubious that the committed
> >> patch was ready.
>
> > While inventing this GUC, I was thinking more about avoiding
> > regress
On Tue, Apr 9, 2024 at 11:37 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> >> * OrClauseGroupKey is not a Node type, so why does it have
> >> a NodeTag? I wonder what value will appear in that field,
> >> and what will happen if the struct
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
>> Yeah, that's one of the reasons I'm dubious that the committed
>> patch was ready.
> While inventing this GUC, I was thinking more about avoiding
> regressions rather than about unleashing the full power of this
> opt
Alexander Korotkov writes:
> On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
>> * OrClauseGroupKey is not a Node type, so why does it have
>> a NodeTag? I wonder what value will appear in that field,
>> and what will happen if the struct is passed to any code
>> that expects real Nodes.
> I used
On Tue, Apr 9, 2024 at 7:27 PM Tom Lane wrote:
> Peter Geoghegan writes:
> > On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> >> I don't know that I'd call it scary exactly, but I do think it
> >> was premature. A week ago there was no consensus that it was
> >> ready to commit, but Alexander
On Tue, Apr 9, 2024 at 8:37 AM Andrei Lepikhov
wrote:
> On 9/4/2024 09:12, Tom Lane wrote:
> > I have another one that I'm not terribly happy about:
> >
> > Author: Alexander Korotkov
> > Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >
> > Transform OR clauses to ANY e
On Tue, Apr 9, 2024 at 5:12 AM Tom Lane wrote:
> * OrClauseGroupKey is not a Node type, so why does it have
> a NodeTag? I wonder what value will appear in that field,
> and what will happen if the struct is passed to any code
> that expects real Nodes.
I used that to put both not-subject-of-tra
On Tue, Apr 9, 2024 at 8:55 AM Tom Lane wrote:
> Andrei Lepikhov writes:
> > On 9/4/2024 09:12, Tom Lane wrote:
> >> I have another one that I'm not terribly happy about:
> >> Author: Alexander Korotkov
> >> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
> >> Transform OR clauses to AN
On Tue, Apr 9, 2024 at 12:27 PM Tom Lane wrote:
> > Some of the most compelling cases for the transformation will involve
> > path keys. If the transformation enables the optimizer to build a
> > plain index scan (or index-only scan) with useful path keys, then that
> > might well lead to a far su
Peter Geoghegan writes:
> On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
>> I don't know that I'd call it scary exactly, but I do think it
>> was premature. A week ago there was no consensus that it was
>> ready to commit, but Alexander pushed it (or half of it, anyway)
>> despite that.
> Some
On Mon, Apr 8, 2024 at 10:12 PM Tom Lane wrote:
> I don't know that I'd call it scary exactly, but I do think it
> was premature. A week ago there was no consensus that it was
> ready to commit, but Alexander pushed it (or half of it, anyway)
> despite that.
Some of the most compelling cases for
> On 9 Apr 2024, at 18:45, Alvaro Herrera wrote:
>
> Maybe we should explicitly advise users to not delete that WAL from
> their archives, until pg_combinebackup is hammered a bit more.
As a backup tool maintainer, I always reference to out-of-the box Postgres
tools as some bulletproof alter
On 2024-Apr-09, Stefan Fercot wrote:
> At some point, the only way to really validate a backup is to actually try to
> restore it.
> And if people get encouraged to do that faster thanks to incremental backups,
> they could detect potential issues sooner.
> Ultimately, users will still need thei
Hi,
On Tuesday, April 9th, 2024 at 2:46 PM, Robert Haas
wrote:
> In all sincerity, I appreciate the endorsement. Basically what's been
> scaring me about this feature is the possibility that there's some
> incurable design flaw that I've managed to completely miss. If it has
> some more garden-v
On 9/4/2024 12:55, Tom Lane wrote:
Andrei Lepikhov writes:
* I really, really dislike jamming this logic into prepqual.c,
where it has no business being. I note that it was shoved
into process_duplicate_ors without even the courtesy of
expanding the header comment:
Yeah, I preferred to do i
On Tue, Apr 9, 2024 at 7:24 AM Tomas Vondra
wrote:
> I think it's a bit more nuanced, because it's about backups/restore. The
> bug might be subtle, and you won't learn about it until the moment when
> you need to restore (or perhaps even long after that). At which point
> "You might have taken th
On 4/9/24 01:33, Michael Paquier wrote:
> On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
>> I don't feel too particularly worried about this. Yes, backups are super
>> important because it's often the only thing you have left when things go
>> wrong, and the incremental aspect is all
On 09.04.24 00:58, Michael Paquier wrote:
That's more linked to the fact that I was going silent without a
laptop for a few weeks before the end of the release cycle, and a way
to say to not count on me, while I was trying to keep my room clean to
avoid noise for others who would rush patches. I
Andrei Lepikhov writes:
> On 9/4/2024 09:12, Tom Lane wrote:
>> I have another one that I'm not terribly happy about:
>> Author: Alexander Korotkov
>> Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
>> Transform OR clauses to ANY expression
>> * What the medical community would call off
On 9/4/2024 09:12, Tom Lane wrote:
I have another one that I'm not terribly happy about:
Author: Alexander Korotkov
Branch: master [72bd38cc9] 2024-04-08 01:27:52 +0300
Transform OR clauses to ANY expression
Because I'm primary author of the idea, let me answer.
I don't k
Robert Haas writes:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
> Hi,
> I'm moving this topic to a new thread for better visibility and less
On Tue, Apr 09, 2024 at 01:16:02AM +0200, Tomas Vondra wrote:
> I don't feel too particularly worried about this. Yes, backups are super
> important because it's often the only thing you have left when things go
> wrong, and the incremental aspect is all new. The code I've seen while
> doing the Co
On 4/8/24 21:47, Robert Haas wrote:
> On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
>> Can you elaborate, which patches you think were not ready? Let's make
>> sure to capture any concrete concerns in the Open Items list.
>
> ...
>
> - Incremental backup could have all sorts of terri
On Tue, Apr 09, 2024 at 09:35:00AM +1200, Thomas Munro wrote:
> Mr Paquier this year announced his personal code freeze a few weeks
> back on social media, which seemed like an interesting idea I might
> adopt. Perhaps that is what some other people are doing without
> saying so, and perhaps the t
On Tue, Apr 9, 2024 at 7:47 AM Robert Haas wrote:
> - The streaming read API stuff was all committed very last minute. I
> think this should have been committed much sooner. It's probably not
> going to break the world; it's more likely to have performance
> consequences. But if it had gone in soo
On Mon, Apr 8, 2024 at 10:42 AM Heikki Linnakangas wrote:
> Can you elaborate, which patches you think were not ready? Let's make
> sure to capture any concrete concerns in the Open Items list.
Hi,
I'm moving this topic to a new thread for better visibility and less
admixture of concerns. I'd li
54 matches
Mail list logo