Re: FETCH FIRST clause WITH TIES option

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Surafel Temesgen <surafel3000(at)gmail(dot)com>
Cc: David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Robert Haas <robertmhaas(at)gmail(dot)com>, andrew(at)tao11(dot)riddles(dot)org(dot)uk, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FETCH FIRST clause WITH TIES option
Date: 2019-04-03 19:02:57
Message-ID: 20190403190257.44fxttkpo4yopp3l@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Unfortunately this got broken again, this time by aef65db676 :-(

I've tried to fix the merge conflict (essentially by moving some of the
code to adjust_limit_rows_costs(), but I'm wondering if the code added to
create_limit_path is actually correct

if (count_est != 0)
{
double count_rows;

if (count_est > 0)
count_rows = (double) count_est;
else
count_rows = clamp_row_est(subpath->rows * 0.10);

if (limitOption == WITH_TIES)
{
...
count_rows = Max(avgGroupSize, count_est + (...));
}
...
}

Firstly, this seriously needs some comment explaining why we do this. But
more importantly - shouldn't it really be

count_rows = Max(avgGroupSize, count_rows + (...));

instead of using count_est again (which might easily be -1 anyway)?

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-04-03 19:08:05 Re: FETCH FIRST clause WITH TIES option
Previous Message Nikolay Shaplov 2019-04-03 18:54:13 Re: [PATCH] src/test/modules/dummy_index -- way to test reloptions from inside of access method