Re: Missing CFI in hlCover()?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Missing CFI in hlCover()?
Date: 2020-07-31 12:36:25
Message-ID: 20200731123625.GB12375@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> Here's a proposed patch along that line.
>
> > I've back-patched this to 11 (which was just a bit of fuzz) and tested
> > it out with a couple of different queries that were causing issues
> > previously on the archive server, and they finish in a much more
> > reasonable time and react faster to cancel requests/signals.
>
> Yeah, I'd tried this locally using the data from the one test case you
> showed me, and it seemed to fix that.

Good stuff.

> > So, looks good to me, and would certainly be nice to get this into the
> > next set of releases, so the archive server doesn't get stuck anymore.
>
> I'll push this tomorrow if nobody has objected to it.

Sounds good.

> BTW, I had noticed last night that hlFirstIndex is being unreasonably
> stupid. Many of the "words" have null item pointers and hence can't
> possibly match any query item (I think because we have "words" for
> inter-word spaces/punctuation as well as the actual words). Checking
> that, as in the attached v2 patch, makes things a bit faster yet.

Nice, looks good to me.

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hamid Akhtar 2020-07-31 12:40:34 Re: track_planning causing performance regression
Previous Message Ashutosh Sharma 2020-07-31 12:32:24 Re: recovering from "found xmin ... from before relfrozenxid ..."