On 10/3/22 16:05, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Based on the above discussion, the RMT asks for a revert of db0d67db2 in
>> the v15 release. The RMT also recommends a revert in HEAD but does not
>> have the power to request that.
>
> Roger, I'll push these shortly.
>
[ Just for the archives' sake at this point, in case somebody has
another go at this feature. ]
I wrote:
> ... I'm now discovering that the code I'd hoped to salvage in
> pathkeys.c (get_useful_group_keys_orderings and related) has its very own
> bugs. It's imagining that it can rearrange a
"Jonathan S. Katz" writes:
> Based on the above discussion, the RMT asks for a revert of db0d67db2 in
> the v15 release. The RMT also recommends a revert in HEAD but does not
> have the power to request that.
Roger, I'll push these shortly.
regards, tom lane
On 10/2/22 8:45 PM, Michael Paquier wrote:
On Sun, Oct 02, 2022 at 02:11:12PM -0400, Tom Lane wrote:
"Jonathan S. Katz" writes:
OK. For v15 I am heavily in favor for the least risky approach given the
point we are at in the release cycle. The RMT hasn’t met yet to discuss,
but from re-reading
On Sun, Oct 02, 2022 at 02:11:12PM -0400, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> OK. For v15 I am heavily in favor for the least risky approach given the
>> point we are at in the release cycle. The RMT hasn’t met yet to discuss,
>> but from re-reading this thread again, I would
David Rowley writes:
> As for the slight misuse of group_pathkeys, I guess since there are no
> users that require just the plain pathkeys belonging to the GROUP BY,
> then likely the best thing would be just to rename that field to
> something like groupagg_pathkeys. Maintaining two separate
On Mon, 3 Oct 2022 at 09:59, Tom Lane wrote:
>
> David Rowley writes:
> > For the master version, I think it's safe just to get rid of
> > PlannerInfo.num_groupby_pathkeys now. I only added that so I could
> > strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
> > pathkeys
David Rowley writes:
> For the master version, I think it's safe just to get rid of
> PlannerInfo.num_groupby_pathkeys now. I only added that so I could
> strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
> pathkeys before passing to the functions that rearranged the GROUP
On Mon, 3 Oct 2022 at 08:10, Tom Lane wrote:
> As attached.
For the master version, I think it's safe just to get rid of
PlannerInfo.num_groupby_pathkeys now. I only added that so I could
strip off the ORDER BY / DISTINCT aggregate PathKeys from the group by
pathkeys before passing to the
"Jonathan S. Katz" writes:
> OK. For v15 I am heavily in favor for the least risky approach given the
> point we are at in the release cycle. The RMT hasn’t met yet to discuss,
> but from re-reading this thread again, I would recommend to revert
> (i.e. the “straight up revert”).
OK by me.
>
> On Oct 2, 2022, at 1:12 PM, Tom Lane wrote:
>
> "Jonathan S. Katz" writes:
>>> On 10/1/22 6:57 PM, Tom Lane wrote:
>>> I plan to have a look tomorrow at the idea of reverting only the cost_sort
>>> changes, and rewriting get_cheapest_group_keys_order() to just sort the
>>> keys by
"Jonathan S. Katz" writes:
> On 10/1/22 6:57 PM, Tom Lane wrote:
>> I plan to have a look tomorrow at the idea of reverting only the cost_sort
>> changes, and rewriting get_cheapest_group_keys_order() to just sort the
>> keys by decreasing numgroups estimates as I suggested upthread. That
>>
On 10/1/22 6:57 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On 10/1/22 3:13 PM, Tom Lane wrote:
I'm still of the opinion that we need to revert this code for now.
[RMT hat, but speaking just for me] reading through Tom's analysis, this
seems to be the safest path forward. I have a few
"Jonathan S. Katz" writes:
> On 10/1/22 3:13 PM, Tom Lane wrote:
>> I'm still of the opinion that we need to revert this code for now.
> [RMT hat, but speaking just for me] reading through Tom's analysis, this
> seems to be the safest path forward. I have a few questions to better
>
On 10/1/22 3:13 PM, Tom Lane wrote:
I'm still of the opinion that we need to revert this code for now.
[RMT hat, but speaking just for me] reading through Tom's analysis, this
seems to be the safest path forward. I have a few questions to better
understand:
1. How invasive would the
Peter Geoghegan writes:
> Reminds me of the other sort testing program that you wrote when the
> B code first went in:
> https://www.postgresql.org/message-id/18732.1142967...@sss.pgh.pa.us
Ha, I'd totally forgotten about that ...
regards, tom lane
On Sat, Oct 1, 2022 at 12:14 PM Tom Lane wrote:
> I spent some time today looking into the question of what our qsort
> code actually does. I wrote a quick-n-dirty little test module
> (attached) to measure the number of comparisons qsort really uses
> for assorted sample inputs.
Reminds me of
I wrote:
> So at this point I've lost all faith in the estimates being meaningful
> at all.
I spent some time today looking into the question of what our qsort
code actually does. I wrote a quick-n-dirty little test module
(attached) to measure the number of comparisons qsort really uses
for
I wrote:
> Given the previous complaints about db0d67db2, I wonder if it's not
> most prudent to revert it. I doubt we are going to get satisfactory
> behavior out of it until there's fairly substantial improvements in
> all these underlying estimates.
After spending some more time looking at
I wrote:
> The most likely theory, I think, is that that compiler is generating
> slightly different floating-point code causing different plans to
> be costed slightly differently than what the test case is expecting.
> Probably, the different orderings of the keys in this test case have
>
Hi,
On 2022-09-30 12:13:11 -0400, Tom Lane wrote:
> "kuroda.hay...@fujitsu.com" writes:
> > Hmm, I was not sure about additional conditions, sorry.
> > I could reproduce with followings steps:
>
> I tried this on a 32-bit VM with gcc 11.3, but couldn't reproduce.
> You said earlier
>
> >> OS:
"kuroda.hay...@fujitsu.com" writes:
> Hmm, I was not sure about additional conditions, sorry.
> I could reproduce with followings steps:
I tried this on a 32-bit VM with gcc 11.3, but couldn't reproduce.
You said earlier
>> OS: RHEL 6.10 server
>> Arch: i686
>> Gcc: 4.4.7
That is an awfully
Dear Tom,
> Hmm, we're not seeing any such failures in the buildfarm's 32-bit
> animals, so there must be some additional condition needed to make
> it happen. Can you be more specific?
Hmm, I was not sure about additional conditions, sorry.
I could reproduce with followings steps:
$ git
"kuroda.hay...@fujitsu.com" writes:
> While running `make check LANC=C` with 32-bit virtual machine,
> I found that it was failed at "aggregates".
Hmm, we're not seeing any such failures in the buildfarm's 32-bit
animals, so there must be some additional condition needed to make
it happen. Can
Hi hackers,
While running `make check LANC=C` with 32-bit virtual machine,
I found that it was failed at "aggregates". PSA the a1b3bca1_regression.diffs.
IIUC that part has been added by db0d67db.
I checked out the source, tested, and got same result. PSA the
db0d67db_regression.diffs
I'm not
25 matches
Mail list logo
