|From:||Dmitry Dolgov <9erthalion6(at)gmail(dot)com>|
|Cc:||Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, pg(at)bowt(dot)ie, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Bhushan Uparkar <bhushan(dot)uparkar(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, James Coleman <jtc331(at)gmail(dot)com>|
|Subject:||Re: Index Skip Scan|
|Views:||Raw Message | Whole Thread | Download mbox|
> On Wed, Nov 21, 2018 at 4:38 PM Alexander Kuzmenkov <a(dot)kuzmenkov(at)postgrespro(dot)ru> wrote:
> On 11/18/18 02:27, Dmitry Dolgov wrote:
> > [0001-Index-skip-scan-v4.patch]
> I ran a couple of tests on this, please see the cases below. As before,
> I'm setting total_cost = 1 for index skip scan so that it is chosen.
> Case 1 breaks because we determine the high key incorrectly, it is the
> second tuple on page or something like that, not the last tuple.
From what I see it wasn't about the high key, just a regular off by one error.
But anyway, thanks for noticing - for some reason it wasn't always
reproduceable for me, so I missed this issue. Please find fixed patch attached.
Also I think it invalidates my previous performance tests, so I would
appreciate if you can check it out too.
> Case 2
> is backwards scan, I don't understand how it is supposed to work. We
> call _bt_search(nextKey = ScanDirectionIsForward), so it seems that it
> just fetches the previous tuple like the regular scan does.
Well, no, it's callled with ScanDirectionIsForward(dir). But as far as I
remember from the previous discussions the entire topic of backward scan is
questionable for this patch, so I'll try to invest some time in it.
|Next Message||Bruce Momjian||2018-11-21 21:27:25||Re: [Proposal] Add accumulated statistics|
|Previous Message||Alvaro Herrera||2018-11-21 19:42:52||Re: [HACKERS] pgbench - allow to store select results into variables|