>> It seems that it contradicts the very idea of your patch, so probably we
>> should look for other ways to optimize this use-case.
>> Maybe this restriction can be relaxed for write only tables, that never
>> have to reread the page because of visibility, or something like that.
>> Also we proba
> It seems that it contradicts the very idea of your patch, so probably we
> should look for other ways to optimize this use-case.
> Maybe this restriction can be relaxed for write only tables, that never
> have to reread the page because of visibility, or something like that.
> Also we probably c
25.08.2019 0:59, Floris Van Nee wrote:
Though, I got interested in the comment inconsistency you have found.
I added debug message into this code branch of the patch and was able to
see it in regression.diffs after 'make check':
Speaking of your patch, it seems that the buffer was unpinned and pi
> Hello,
> welcome to hackers with your first patch)
Thank you.
> Though, I got interested in the comment inconsistency you have found.
> I added debug message into this code branch of the patch and was able to
> see it in regression.diffs after 'make check':
> Speaking of your patch, it seems t
On Fri, Aug 23, 2019 at 10:14 AM Anastasia Lubennikova
wrote:
> Though, I got interested in the comment inconsistency you have found.
> I added debug message into this code branch of the patch and was able to
> see it in regression.diffs after 'make check':
> Speaking of your patch, it seems that
05.08.2019 14:34, Floris Van Nee wrote:
I have one further question about these index offsets. There are several
comments in master that indicate that it's impossible that an item moves 'left'
on a page, if we continuously hold a pin on the page. For example,
_bt_killitems has a comment like t
Hi Peter,
> Actually, having looked at the test case in more detail, that now
> seems less likely. The test case seems designed to reward making it
> cheaper to access one specific tuple among a fairly large group of
> related tuples -- reducing the number of inner scans is not going to
> be possi
Hello everyone.
I am also was looking into possibility of such optimisation few days ago
(attempt to reduce memcpy overhead on IndexOnlyScan).
One thing I noticed here - whole page is scanned only if index quals are
"opened" at some side.
So, in case of
SELECT* FROM tbl WHERE k=:val AND ts
On Fri, Aug 2, 2019 at 5:34 PM Peter Geoghegan wrote:
> I wonder if some variety of block nested loop join would be helpful
> here. I'm not aware of any specific design that would help with
> Floris' case, but the idea of reducing the number of scans required on
> the inner side by buffering outer
On Fri, Aug 2, 2019 at 1:43 PM Tom Lane wrote:
> Meh. I think the odds that you got this 100% right are small, and the
> odds that it would be maintainable are smaller. There's too much that
> can happen if you're not holding any lock --- and there's a lot of active
> work on btree indexes, whic
Hi Tom,
Thanks for your quick reply!
> Regardless of whether there's actually a LIMIT 1? That seems disastrous
> for every other case than the narrow one where the optimization wins.
> Because every other case is now going to have to touch the index page
> twice. That's more CPU and about doubl
Floris Van Nee writes:
> Every time the index scan is done, all tuples from the leaf page are
> read in nbtsearch.c:_bt_readpage. The idea of this patch is to make an
> exception for this *only* the first time amgettuple gets called.
Regardless of whether there's actually a LIMIT 1? That seems d
ith simple unique equality select
- test_fwd_single.sql: single query with LIMIT without nested loop
-Floris
0001-Optimize-single-tuple-fetch-from-nbtree-index-v01.patch
Description: 0001-Optimize-single-tuple-fetch-from-nbtree-index-v01.patch
init_test.sql
Description: init_test.sql
+
13 matches
Mail list logo
