Subject: Re: Tid scan improvements
To: Edmund Horner <ejrh00@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
 David Rowley <david.rowley@2ndquadrant.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
References: 
 <CAMyN-kA-cdPN5+W8Nx5tC=pyHpxhXOngO_rQ0+PPzGgf6ZGghw@mail.gmail.com>
 <24929.1547829356@sss.pgh.pa.us>
 <CAMyN-kDaFgpkbYw1dVSvADp4KZisq7oNdaQ1GkyVAqEZ0Xvk=Q@mail.gmail.com>
 <CAMyN-kCnmBq7b-CJ3NVyV1b0A-1SrzwoP1Y=a403iPa1_Vrb+g@mail.gmail.com>
 <CAKJS1f9f+1CEyT3_mv9kN-Le=npqS-0iyZgqPDgCrFYKEAACKA@mail.gmail.com>
 <CAMyN-kC1Eacuk6LAMYH9-M9ddfn6JF1_kJZZedSH8gh7Ljckew@mail.gmail.com>
 <CAKJS1f9Rd1nYmk4AX+EZ09jCzxaYS9dQey3CuM3kKyTwFZjQYg@mail.gmail.com>
 <CAMyN-kCRiXB50Sx_Ftwb9YFQG5Se99eLkzPPbU34qvpTdQa-2w@mail.gmail.com>
 <CAMyN-kAWZHXXmB0KyZoj_Y7HSU+4H4hYNutuTqXiTveQFQueHA@mail.gmail.com>
 <CAKJS1f9DBpoZk5Fhyq5eQu3YfAWo8E7J2zEPSz70J=im8rVngw@mail.gmail.com>
 <20190325215211.bhwf35lihihfdx5w@alap3.anarazel.de>
 <18054.1553554436@sss.pgh.pa.us>
 <CAMyN-kAUk5v5y=+L_gCQ227qUFPdCV0JU=XTxALNHWVRFkiSzA@mail.gmail.com>
From: David Steele <david@pgmasters.net>
Message-ID: <fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net>
Date: Tue, 26 Mar 2019 08:24:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0)
 Gecko/20100101 Thunderbird/60.6.0
MIME-Version: 1.0
In-Reply-To: 
 <CAMyN-kAUk5v5y=+L_gCQ227qUFPdCV0JU=XTxALNHWVRFkiSzA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 3/26/19 8:11 AM, Edmund Horner wrote:
> On Tue, 26 Mar 2019 at 11:54, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> Andres Freund <andres@anarazel.de> writes:
>>> I was kinda hoping to keep block numbers out of the "main" APIs, to
>>> avoid assuming everything is BLCKSZ based. I don't have a particular
>>> problem allowing an optional setscanlimits type callback that works with
>>> block numbers. The planner could check its presence and just not build
>>> tid range scans if not present.  Alternatively a bespoke scan API for
>>> tid range scans, like the later patches in the tableam series for
>>> bitmap, sample, analyze scans, might be an option.
>>
>> Given Andres' API concerns, and the short amount of time remaining in
>> this CF, I'm not sure how much of this patch set we can expect to land
>> in v12.  It seems like it might be a good idea to scale back our ambitions
>> and see whether there's a useful subset we can push in easily.
> 
> I agree.  It'll take some time to digest Andres' advice and write a
> better patch.
> 
> Should I set update CF app to a) set the target version to 13, and/or
> move it to next commitfest?

If you plan to continue working on it in this CF then you can just 
change the target to PG13.  If you plan to take a break and pick up the 
work later then go ahead and push it to the next CF.

Regards,
-- 
-David
david@pgmasters.net