From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Missing CFI in hlCover()? |
Date: | 2020-07-31 01:25:22 |
Message-ID: | 1660074.1596158722@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-slow-ts_headline-2.patch | text/x-diff | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2020-07-31 01:33:32 | Re: HashAgg's batching counter starts at 0, but Hash's starts at 1. (now: incremental sort) |
Previous Message | Robert Haas | 2020-07-31 00:53:32 | Re: new heapcheck contrib module |