Re: Tid scan improvements

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Edmund Horner <ejrh00(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, tomas(dot)vondra(at)2ndquadrant(dot)com, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Tid scan improvements
Date: 2018-12-20 23:10:44
Message-ID: 20181220231044.v3c6uqxslqi4ui2q@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-12-20 18:06:41 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-12-20 17:21:07 -0500, Tom Lane wrote:
> >> I'm having a hard time wrapping my mind around why you'd bother with
> >> backwards TID scans.
>
> > 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).
>
> Sure, but wouldn't you now write those using something on the order of
>
> WHERE ctid >= '(cutoff_page_here, 1)'
>
> ? I don't see that you'd want to write "ORDER BY ctid DESC LIMIT n"
> because you wouldn't know what value of n to use to get all the
> tuples on some-number-of-ending-pages.

I think you'd want both, to make sure there's not more tuples than
estimated. With the limit calculated to ensure there's enough free space
for them to actually fit.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-12-20 23:38:02 pgsql: Check for conflicting queries during replay of gistvacuumpage()
Previous Message Tom Lane 2018-12-20 23:06:41 Re: Tid scan improvements