Hi!
No objections. Alexander, thank you!
--
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On Wed, Mar 5, 2025 at 1:20 PM Alexander Korotkov wrote:
> On Wed, Mar 5, 2025 at 8:32 AM Andrei Lepikhov wrote:
> > On 5/3/2025 03:27, Alexander Korotkov wrote:
> > > On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
> > >>> 2. As usage of root->tuple_fraction RelOptInfo it has been critici
On Wed, Mar 5, 2025 at 8:32 AM Andrei Lepikhov wrote:
> On 5/3/2025 03:27, Alexander Korotkov wrote:
> > On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
> >>> 2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
> >>> do you think we could limit this to some simple cases?
On 5/3/2025 03:27, Alexander Korotkov wrote:
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
2. As usage of root->tuple_fraction RelOptInfo it has been criticized,
do you think we could limit this to some simple cases? For instance,
check that RelOptInfo is the final result relation for
On Mon, Mar 3, 2025 at 1:04 PM Andrei Lepikhov wrote:
>
> On 2/3/2025 09:53, Alexander Korotkov wrote:
> > Hi, Andrei!
> >
> > On Fri, Dec 6, 2024 at 10:13 AM Andrei Lepikhov wrote:
> >>
> >> On 12/6/24 13:48, Andrei Lepikhov wrote:
> >>> On 11/2/24 01:18, Nikita Malakhov wrote:
> I've corre
On 03.03.2025 14:17, Alena Rybakina wrote:
Hi! Thank you for your work on this subject.
I agree with your code but one phrase in commit message was confusing
for me:
"This change is dedicated to more active usage of IndexScan and
parameterised
NestLoop paths in partitioned cases under an App
Hi! Thank you for your work on this subject.
I agree with your code but one phrase in commit message was confusing
for me:
"This change is dedicated to more active usage of IndexScan and
parameterised
NestLoop paths in partitioned cases under an Append node, as it already
works
with plain t
On 2/3/2025 09:53, Alexander Korotkov wrote:
Hi, Andrei!
On Fri, Dec 6, 2024 at 10:13 AM Andrei Lepikhov wrote:
On 12/6/24 13:48, Andrei Lepikhov wrote:
On 11/2/24 01:18, Nikita Malakhov wrote:
I've corrected failing test and created a patch at Commitfest:
https://commitfest.postgresql.org/
Hi, Andrei!
On Fri, Dec 6, 2024 at 10:13 AM Andrei Lepikhov wrote:
>
> On 12/6/24 13:48, Andrei Lepikhov wrote:
> > On 11/2/24 01:18, Nikita Malakhov wrote:
> >> I've corrected failing test and created a patch at Commitfest:
> >> https://commitfest.postgresql.org/51/5361/ >> commitfest.postgresq
Hi, Andy!
On Fri, Oct 18, 2024 at 3:55 AM Andy Fan wrote:
>
> Nikita Malakhov writes:
>
>
> > The effect is easily seen in one of standard PG tests:
> > Vanilla (current master):
> > explain analyze
> > select t1.unique1 from tenk1 t1
> > inner join tenk2 t2 on t1.tenthous = t2.tenthous and t2.t
On 12/6/24 13:48, Andrei Lepikhov wrote:
On 11/2/24 01:18, Nikita Malakhov wrote:
I've corrected failing test and created a patch at Commitfest:
https://commitfest.postgresql.org/51/5361/ commitfest.postgresql.org/51/5361/>
I have played around with this feature, which looks promising for such a
On 11/2/24 01:18, Nikita Malakhov wrote:
I've corrected failing test and created a patch at Commitfest:
https://commitfest.postgresql.org/51/5361/ commitfest.postgresql.org/51/5361/>
I have played around with this feature, which looks promising for such a
tiny change. It provides a 'bottom bound
Hi!
I've checked set_subquery_pathlist(), and would rather say that it has
a different purpose and I'd better not compare these functions directly.
generate_orderedappend_paths() was introduced 6 years ago, and
commit that considers tuple_fraction authored by Tomas Vondra
was suggested by Tom Lan
Nikita Malakhov writes:
> Hi,
>
> Andy, thank you, I've checked this thread out along with run-time
> partition pruning.
I'm not sure the relationshipe between this topic and run-time
partitioin pruning..
> I've spend some time hovering on the tuple_fraction field usage and would
> disagree
> w
Hi,
Andy, thank you, I've checked this thread out along with run-time partition
pruning.
I've spend some time hovering on the tuple_fraction field usage and would
disagree
with you on this topic - it is already used on the RelOptInfo level later
on, in
generate_orderedappend_paths()
I mean the fol
Nikita Malakhov writes:
Hi Nikita,
> Hi!
>
> Andy, one quick question - what do you think on using
> root->limit_tuples as a guidance on how many
> rows we have to consider in plans cost?
Within my exprerience, the committer probabaly dislikes the idea of
"ignoring the difference of tuple_fra
Hi!
Andy, one quick question - what do you think on using root->limit_tuples as
a guidance on how many
rows we have to consider in plans cost?
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
On 10/18/24 07:54, Andy Fan wrote:
Nikita Malakhov writes:
The effect is easily seen in one of standard PG tests:
"""
I think that things might work out better if we redefined the startup
cost as "estimated cost to retrieve the first tuple", rather than its
current very-squishy definition as "
Nikita Malakhov writes:
> The effect is easily seen in one of standard PG tests:
> Vanilla (current master):
> explain analyze
> select t1.unique1 from tenk1 t1
> inner join tenk2 t2 on t1.tenthous = t2.tenthous and t2.thousand = 0
>union all
> (values(1)) limit 1;
>
Nikita Malakhov writes:
> Hi,
>
> Andy, your words make sense, but to me it seems that in
> add_paths_to_append_rel
> we have no other options than tuple_fraction from root, and rows (if any) in
> paths
> we take into account, please correct me if I am wrong.
One of the option might be applyin
Hi,
Andy, your words make sense, but to me it seems that in
add_paths_to_append_rel
we have no other options than tuple_fraction from root, and rows (if any)
in paths
we take into account, please correct me if I am wrong.
Thank you!
Also, on top of that I have an idea of pruning unnecessary part
On 10/17/24 07:05, Andy Fan wrote:
Nikita Malakhov writes:
Helll Nikita,
Hi hackers!
Sorry, I've forgot to attach the patch itself. Please check it out.
Could you check if [1] is related to this subject? I think the hard part
would be which tuple_fraction to use during adding
add_paths_to_
Nikita Malakhov writes:
Helll Nikita,
> Hi hackers!
>
> Sorry, I've forgot to attach the patch itself. Please check it out.
Could you check if [1] is related to this subject? I think the hard part
would be which tuple_fraction to use during adding
add_paths_to_append_rel since root->tuple_fract
Hi hackers!
Sorry, I've forgot to attach the patch itself. Please check it out.
--
Regards,
Nikita Malakhov
Postgres Professional
The Russian Postgres Company
https://postgrespro.ru/
0001_append_limit_v1.patch
Description: Binary data
24 matches
Mail list logo
