From: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
---|---|
To: | amborodin(at)acm(dot)org |
Cc: | Shubham Barai <shubhambaraiss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, David Steele <david(at)pgmasters(dot)net> |
Subject: | Re: GSoC 2017 weekly progress reports (week 2) |
Date: | 2017-06-13 20:24:35 |
Message-ID: | CACjxUsOdWqHZ1ixhR6h2GVDwVM8530LPxAQDuUEqGys8b+1=Og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 13, 2017 at 1:02 PM, Andrew Borodin <borodin(at)octonica(dot)com> wrote:
> 2017-06-13 18:00 GMT+05:00 Shubham Barai <shubhambaraiss(at)gmail(dot)com>:
> Good job!
+1! :-)
> So, in current HEAD test predicate_gist_2.spec generate false
> positives, but with your patch, it does not?
Keep in mind, that false positives do not break *correctness* of serializable
transactions as long as it involves another transaction. (It *would* be a bug
if a transaction running alone could cause a serialization failure.) A false
*negative* is always a bug.
That said, false positives hurt performance, so we should keep the rate as low
as practicable.
> I'd suggest keeping spec tests with your code in the same branch, it's
> easier.
+1
> Also it worth to clean up specs style and add some words to
> documentation.
+1
> Kevin, all, how do you think, is it necessary to expand these tests
> not only on Index Only Scan, but also on Bitmap Index Scan? And may be
> KNN version of scan too?
> I couldn't find such tests for B-tree, do we have them?
Off-hand, I don't know. It would be interesting to run regression tests with
code coverage and look at the index AMs.
https://www.postgresql.org/docs/9.6/static/regress-coverage.html
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-06-13 20:36:07 | Re: A bug in mapping attributes in ATExecAttachPartition() |
Previous Message | Tom Lane | 2017-06-13 20:23:39 | Re: pgindent (was Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.) |