Date: Thu, 20 Dec 2018 14:33:59 -0800
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Edmund Horner <ejrh00@gmail.com>,
	David Rowley <david.rowley@2ndquadrant.com>,
	tomas.vondra@2ndquadrant.com,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Tid scan improvements
Message-ID: <20181220223359.beygiujulocdbmas@alap3.anarazel.de>
References: 
 <CAMyN-kAO-bc5pqgRp1vZ=gFmVjbEQfM7Anikkm6PPDDAekH2Nw@mail.gmail.com>
 <CAKJS1f8Ap6cFKeBbTnHXpOcgq5iXV1UhwA7ZiP4fxxx1LArbwQ@mail.gmail.com>
 <CAMyN-kBRYy=DV3oQ0TD6pJYvNg1oHSTXdCTe94XJGOpJK1GeAA@mail.gmail.com>
 <CAMyN-kB6+KTyH3TQqoLLbNtj2t4AZr8RMHUU0yzxp429o5PyDw@mail.gmail.com>
 <CAKJS1f9+etR1VGkqp=hkGWn3EofWJVFnjKaTpHZva2PKhALdng@mail.gmail.com>
 <CAMyN-kCLxCo=rbysFRM=Ouarp+xd_b=oP26+tr1yXe3C9k89OQ@mail.gmail.com>
 <CAMyN-kDNyqy2RUGn53GnoS1shdB5TYhif9OpGFFkOb7z=za2eQ@mail.gmail.com>
 <CAKJS1f9TG!bBMNsDK+wXtGpVL2=73cmB9=NBxUk9Wp9OH59kg7Q@mail.gmail.com>
 <CAMyN-kAaB1D5b1kLJc9f_XYG5zPhaFCqc-6dWyGy=1JB3Tw2Rw@mail.gmail.com>
 <8469.1545344467@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8469.1545344467@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2018-12-20 17:21:07 -0500, Tom Lane wrote:
> Edmund Horner <ejrh00@gmail.com> writes:
> > [ tid scan patches ]
> 
> I'm having a hard time wrapping my mind around why you'd bother with
> backwards TID scans.  The amount of code needed versus the amount of
> usefulness seems like a pretty bad cost/benefit ratio, IMO.  I can
> see that there might be value in knowing that a regular scan has
> "ORDER BY ctid ASC" pathkeys (mainly, that it might let us mergejoin
> on TID without an explicit sort).  It does not, however, follow that
> there's any additional value in supporting the DESC case.

I've not followed this thread, but wouldn't that be quite useful to be
able to move old tuples to free space earlier in the table?

I've written multiple scripts that update the later pages in a table, to
force reuse of earlier free pages (in my case by generating ctid = ANY()
style queries with all possible tids for the last few pages, the most
efficient way I could think of).

Greetings,

Andres Freund