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

help / color / mirror / Atom feed
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Edmund Horner <ejrh00@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: tomas.vondra@2ndquadrant.com, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Tid scan improvements
Date: Thu, 20 Dec 2018 14:33:59 -0800
Message-ID: <20181220223359.beygiujulocdbmas@alap3.anarazel.de> (raw)
In-Reply-To: <8469.1545344467@sss.pgh.pa.us>
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>

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




view thread (97+ messages)  latest in thread

Message-ID: <20181220223359.beygiujulocdbmas@alap3.anarazel.de>
Permalink:  ../20181220223359.beygiujulocdbmas@alap3.anarazel.de/
Also on:    postgresql.org/message-id/20181220223359.beygiujulocdbmas@alap3.anarazel.de

 · 

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

* 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