Alvaro Herrera writes:
> Thanks, pushed.
Pushed the original patch now too.
regards, tom lane
On 2022-Jul-19, Richard Guo wrote:
> On Tue, Jul 19, 2022 at 1:30 AM Tom Lane wrote:
> > WFM. (I'd fixed the comment typo in my patch, but I don't mind if
> > you get there first.)
Ah, I see now you had other grammatical fixes and even more content
there.
> +1 The fix looks good to me.
Thank
On Tue, Jul 19, 2022 at 1:30 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2022-Jul-18, Richard Guo wrote:
> >> BTW, not related to this patch, the new lines for parallel_aware check
> >> in setrefs.c are very wide. How about wrap them to keep consistent with
> >> arounding codes?
>
> > Not
Alvaro Herrera writes:
> On 2022-Jul-18, Richard Guo wrote:
>> BTW, not related to this patch, the new lines for parallel_aware check
>> in setrefs.c are very wide. How about wrap them to keep consistent with
>> arounding codes?
> Not untrue! Something like this, you mean? Fixed the nearby typo
On 2022-Jul-18, Richard Guo wrote:
> BTW, not related to this patch, the new lines for parallel_aware check
> in setrefs.c are very wide. How about wrap them to keep consistent with
> arounding codes?
Not untrue! Something like this, you mean? Fixed the nearby typo while
at it.
--
Álvaro Herr
On Mon, Jul 18, 2022 at 3:16 AM Tom Lane wrote:
> I wrote:
> > I also notice that setrefs.c can elide Append and MergeAppend nodes
> > too in some cases, but AFAICS costing of those node types doesn't
> > take that into account.
>
> I took a closer look at this point and realized that in fact,
>
I wrote:
> I also notice that setrefs.c can elide Append and MergeAppend nodes
> too in some cases, but AFAICS costing of those node types doesn't
> take that into account.
I took a closer look at this point and realized that in fact,
create_append_path and create_merge_append_path do attempt to a
On Thu, May 5, 2022 at 4:30 PM Richard Guo wrote:
> On Thu, May 5, 2022 at 7:03 AM Tom Lane wrote:
>> 1015 improvements to 14 disimprovements isn't a bad score. I'm
>> a bit surprised there are that many removable SubqueryScans TBH;
>> maybe that's an artifact of all the "SELECT *" queries.
> T
On Thu, May 5, 2022 at 7:03 AM Tom Lane wrote:
> I wrote:
> > I instrumented the code in setrefs.c, and found that during the
> > core regression tests this patch estimates correctly in 2103
> > places while guessing wrongly in 54, so that seems like a pretty
> > good step forward.
>
> On second
I wrote:
> I instrumented the code in setrefs.c, and found that during the
> core regression tests this patch estimates correctly in 2103
> places while guessing wrongly in 54, so that seems like a pretty
> good step forward.
On second thought, that's not a terribly helpful summary. Breaking
thin
In [1] I complained about how SubqueryScans that get deleted from
a plan tree by setrefs.c nonetheless contribute cost increments
that might cause the planner to make odd choices. That turned
out not to be the proximate cause of that particular issue, but
it still seems like it might be a good ide
11 matches
Mail list logo
