| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Why we lost Uber as a user |
| Date: | 2016-07-29 15:16:25 |
| Message-ID: | 20160729151625.GD17219@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jul 29, 2016 at 10:44:29AM -0400, Stephen Frost wrote:
> Another thought that was kicking around in my head related to that is if
> we could have indexes that only provide page-level information (similar
> to BRIN, but maybe a btree) and which also would allow HOT updates.
> Those indexes would typically be used in a bitmap index scan where we're
> going to be doing a bitmap heap scan with a recheck, of course, though I
> wonder if we could come up with a way to do an in-order bitmap index
> scan where we sort the tuples on the page and then perform some kind of
> mergejoin recheck (or just pull out whatever the lowest-not-seen each
> time we sort the tuples on the page).
So allow HOT updates if the updated row is on the same page, even if the
indexed column was changed, by scanning the page --- got it.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2016-07-29 15:27:06 | Re: sslmode=require fallback |
| Previous Message | Bruce Momjian | 2016-07-29 15:13:30 | Re: sslmode=require fallback |