Re: CURRENT OF causes an error when IndexOnlyScan is used
От | Tom Lane |
---|---|
Тема | Re: CURRENT OF causes an error when IndexOnlyScan is used |
Дата | |
Msg-id | 13902.1520877384@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: CURRENT OF causes an error when IndexOnlyScan is used (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>) |
Ответы |
Re: CURRENT OF causes an error when IndexOnlyScan is used
|
Список | pgsql-hackers |
Anastasia Lubennikova <a.lubennikova@postgrespro.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
В списке pgsql-hackers по дате отправления: