Horton
Menu

Re: Why we lost Uber as a user

Simon Riggs <simon@2ndquadrant.com>

View thread
From: Simon Riggs <simon@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>, Alex Ignatov <a.ignatov@postgrespro.ru>, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>, Josh Berkus <josh@agliodbs.com>, Robert Haas <robertmhaas@gmail.com>, "Joshua D. Drake" <jd@commandprompt.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-03T07:20:46Z
Lists: pgsql-hackers 
On 29 July 2016 at 15:44, Stephen Frost <sfrost@snowman.net> wrote:

> All very hand-wavy, of course, and it'd make sense to make the concept
> work for BRIN before we consider anything else, but it seems like there
> could be a use-case for allowing indexes other than BRIN to be built in
> a way that allows HOT updates to happen, thus eliminating the cost of
> having to update those indexes when the tuple is changed, in many cases.
> Of course, those indexes couldn't be used UNIQUE indexes or used for
> primary keys, and adjusting the parameters to a BRIN index you could
> possibly get a similar index, but this might allow such an index to
> still be usable for index-only scans, which a BRIN index will never be
> able to provide.

This idea is vaguely similar to the concepts I've been working on,
based on earlier work in 2007.

I'm starting a new post for a full discussion.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Advance backend's advertised xmin more aggressively.

  2. Improve snapshot manager by keeping explicit track of snapshots.