2024-01 Commitfest.
Hi, This patch has a CF status of "Needs Review", but it seems like
there were some CFbot test failures last time it was run [1]. Please
have a look and post an updated version if necessary.
==
[1]
Heikki Linnakangas writes:
> On 29/12/2023 01:42, Tom Lane wrote:
>> I didn't stop to trace the details but I'm pretty sure this is why
>> you're getting the bogus extra projections shown in the 0005 patch.
> They're not bogus. With the patches, projecting away the junk columns is
> visible in
On 29/12/2023 01:42, Tom Lane wrote:
I wrote:
Yeah, fair point. I'll try to take a look at your patchset after
the holidays.
I spent some time looking at this patch, and I'm not very pleased
with it. My basic complaint is that this is a band-aid that only
touches things at a surface level,
I wrote:
> Yeah, fair point. I'll try to take a look at your patchset after
> the holidays.
I spent some time looking at this patch, and I'm not very pleased
with it. My basic complaint is that this is a band-aid that only
touches things at a surface level, whereas I think we need a much
deeper
On Fri, Dec 22, 2023 at 2:38 AM Heikki Linnakangas wrote:
> v1-0004-Omit-columns-from-final-tlist-that-were-only-need.patch
>
> The main patch in this series.
This patch filters out the junk columns created for ORDER BY/GROUP BY,
and retains the junk columns created for RowLocks. I'm afraid
On Sat, Dec 23, 2023 at 1:32 AM Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 22/12/2023 17:24, Tom Lane wrote:
> >> How much of your patchset still makes sense if we assume that we
> >> can always extract the ORDER BY column values from the index?
>
> > That would make it much less
Heikki Linnakangas writes:
> On 22/12/2023 17:24, Tom Lane wrote:
>> How much of your patchset still makes sense if we assume that we
>> can always extract the ORDER BY column values from the index?
> That would make it much less interesting. But I don't think that's a
> good assumption.
On 22/12/2023 17:24, Tom Lane wrote:
Heikki Linnakangas writes:
It won't
help in all cases though, the index might not store the original value
in the first place.
I'm a little skeptical that an index could produce an accurate ORDER BY
result if it doesn't store the values-to-be-sorted
Heikki Linnakangas writes:
> Hmm, so return the computed column from the index instead of recomputing
> it? Yeah, that makes sense too and would help in this example.
Yeah, that's been on the to-do list for ages. The main problems are
(1) we need the planner to not spend too much effort on
On 22/12/2023 11:05, Xiaoran Wang wrote:
I haven't dug into your patch yet, but for this problem, I have another
idea.
---
explain verbose
select foo from mytable order by sha256(bar::bytea);
QUERY PLAN
Hi Heikii,
I haven't dug into your patch yet, but for this problem, I have another
idea.
---
explain verbose
select foo from mytable order by sha256(bar::bytea);
QUERY PLAN
11 matches
Mail list logo
