pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: Edmund Horner <ejrh00@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Tid scan improvements
Date: Mon, 25 Mar 2019 18:53:56 -0400
Message-ID: <18054.1553554436@sss.pgh.pa.us> (raw)
In-Reply-To: <20190325215211.bhwf35lihihfdx5w@alap3.anarazel.de>
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>

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.

With that in mind, I went ahead and pushed 0001+0004, since improving
the planner's selectivity estimate for a "ctid vs constant" qual is
likely to be helpful whether the executor is smart about it or not.

FWIW, I don't really see the point of treating 0002 as a separate patch.
If it had some utility on its own, then it'd be sensible, but what
would that be?  Also, it looks from 0002 like you are trying to overload
rs_startblock with a different meaning than it has for syncscans, and
I think that might be a bad idea. 

			regards, tom lane




view thread (97+ messages)  latest in thread

Message-ID: <18054.1553554436@sss.pgh.pa.us>
Permalink:  ../18054.1553554436@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/18054.1553554436@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, andres@anarazel.de, david.rowley@2ndquadrant.com, ejrh00@gmail.com, tomas.vondra@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Tid scan improvements
  In-Reply-To: <18054.1553554436@sss.pgh.pa.us>

* 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