Re: FETCH FIRST clause WITH TIES option

From: Surafel Temesgen <surafel3000(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Subject: Re: FETCH FIRST clause WITH TIES option
Date: 2019-11-28 13:37:12
Message-ID: CALAY4q82MDk1cehn-n2sSPu0iOLttXGk4A_CdXHnUSnQpK5sFA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 28, 2019 at 12:36 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Thanks.
>
> (I would suggest renaming the new state LIMIT_WINDOWEND_TIES, because it
> seems to convey what it does a little better.)
>
> I think you should add a /* fall-though */ comment after changing state.
> Like this (this flow seems clearer; also DRY):
>
> if (!node->noCount &&
> node->position - node->offset >= node->count)
> {
> if (node->limitOption == LIMIT_OPTION_COUNT)
> {
> node->lstate = LIMIT_WINDOWEND;
> return NULL;
> }
> else
> {
> node->lstate = LIMIT_WINDOWEND_TIES;
> /* fall-through */
> }
> }
> else
> ...
>
>
changed

> I've been playing with this a little more, and I think you've overlooked
> a few places in ExecLimit that need to be changed. In the regression
> database, I tried this:
>
> 55432 13devel 17282=# begin;
> BEGIN
> 55432 13devel 17282=# declare c1 cursor for select * from int8_tbl order
> by q1 fetch first 2 rows with ties;
> DECLARE CURSOR
> 55432 13devel 17282=# fetch all in c1;
> q1 │ q2
> ─────┼──────────────────
> 123 │ 456
> 123 │ 4567890123456789
> (2 filas)
>
> 55432 13devel 17282=# fetch all in c1;
> q1 │ q2
> ────┼────
> (0 filas)
>
> 55432 13devel 17282=# fetch forward all in c1;
> q1 │ q2
> ────┼────
> (0 filas)
>
> So far so good .. things look normal. But here's where things get
> crazy:
>
> 55432 13devel 17282=# fetch backward all in c1;
> q1 │ q2
> ──────────────────┼──────────────────
> 4567890123456789 │ 123
> 123 │ 4567890123456789
> (2 filas)
>
> (huh???)
>
> 55432 13devel 17282=# fetch backward all in c1;
> q1 │ q2
> ────┼────
> (0 filas)
>
> Okay -- ignoring the fact that we got a row that should not be in the
> result, we've exhausted the cursor going back. Let's scan it again from
> the start:
>
> 55432 13devel 17282=# fetch forward all in c1;
> q1 │ q2
> ──────────────────┼───────────────────
> 123 │ 4567890123456789
> 4567890123456789 │ 123
> 4567890123456789 │ 4567890123456789
> 4567890123456789 │ -4567890123456789
> (4 filas)
>
> This is just crazy.
>
> I think you need to stare a that thing a little harder.
>
>
This is because the new state didn't know about backward scan
and there was off by one error it scan one position past to detect
ties. The attached patch fix both
regards
Surafel

Attachment Content-Type Size
fetch_first_with_ties_v14.patch text/x-patch 39.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-11-28 13:37:17 Re: progress report for ANALYZE
Previous Message Rafia Sabih 2019-11-28 13:23:21 Re: How to prohibit parallel scan through tableam?