Re: CURRENT OF causes an error when IndexOnlyScan is used

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
Subject: Re: CURRENT OF causes an error when IndexOnlyScan is used
Date: 2018-03-12 17:56:24
Message-ID: 13902.1520877384@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:
> [ return_heaptuple_in_btree_indexonlyscan_v2.patch ]

I took a quick look at this, but I'm concerned about a couple of points:

1. What's the performance penalty of forming (and then deforming) the
added heap tuple? We'd be paying it for every index-only scan, whether
or not any CURRENT OF fetch ever happened.

2. The constructed tuple provides tableoid and ctid all right, but it'd
still have garbage values for other system columns. As the code stands,
we will properly error out if some attempt is made to fetch any of those
other columns, but with this change we'd just return the garbage. This
is a minor point, but it doesn't seem negligible to me; it might've been
hard to identify the bug at hand if we'd not had the cross-check of not
building a heap tuple.

At this point Yugo-san's original patch is starting to look more
attractive. It's still ugly, but at least it's not imposing a performance
cost on unrelated queries.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-12 18:06:51 Re: Ambigous Plan - Larger Table on Hash Side
Previous Message Andres Freund 2018-03-12 17:43:14 Re: Ambigous Plan - Larger Table on Hash Side