Re: [HACKERS] GSoC 2017 weekly progress reports (week 2) - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: [HACKERS] GSoC 2017 weekly progress reports (week 2)
Date
Msg-id CACjxUsOdWqHZ1ixhR6h2GVDwVM8530LPxAQDuUEqGys8b+1=Og@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] GSoC 2017 weekly progress reports (week 2)  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
On Tue, Jun 13, 2017 at 1:02 PM, Andrew Borodin <borodin@octonica.com> wrote:
> 2017-06-13 18:00 GMT+05:00 Shubham Barai <shubhambaraiss@gmail.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/



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgindent (was Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run.)
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()