pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: David Steele <david@pgmasters.net>
To: Edmund Horner <ejrh00@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Tid scan improvements
Date: Tue, 26 Mar 2019 08:24:30 +0200
Message-ID: <fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net> (raw )
In-Reply-To: <CAMyN-kAUk5v5y=+L_gCQ227qUFPdCV0JU=XTxALNHWVRFkiSzA@mail.gmail.com >
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 >
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
view thread (97+ messages) latest in thread
Message-ID: <fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net>
Permalink: ../fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net/
Also on: postgresql.org/message-id/fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: david@pgmasters.net, ejrh00@gmail.com, tgl@sss.pgh.pa.us, andres@anarazel.de, david.rowley@2ndquadrant.com, tomas.vondra@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Tid scan improvements
In-Reply-To: <fa74cd01-ba29-9d9a-6131-1fabbc244ddc@pgmasters.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox