From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The case for removing replacement selection sort |
Date: | 2017-09-29 16:20:55 |
Message-ID: | CAH2-WznO8BDxyMG=QbqzytrOLuys0mrcYRsvcfTjYVic7ManZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 29, 2017 at 7:19 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> That supports your theory that there's some confounding factor in the
> CREATE INDEX case, such as I/O scheduling. Since this machine has an
> SSD, I guess I don't have a mental model for how that works. We're
> not waiting for the platter to rotate...
Random I/O is still significantly more expensive with SSDs, especially
random writes, where all the wear leveling stuff comes into play.
There is a tiny universe of very complicated firmware within every SSD
[1]. (I am generally concerned about the trend towards increasingly
complicated, unauditable firmware like this, but that's another
story.)
> ...but I guess that's all irrelevant as far as this patch goes. The
> point of this patch is to simplify things from removing a technique
> that is no longer effective, and the evidence we have supports the
> contention that it is no longer effective. I'll go commit this.
Thanks.
[1] https://lwn.net/Articles/353411/
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-09-29 16:28:20 | Re: path toward faster partition pruning |
Previous Message | Robert Haas | 2017-09-29 16:17:05 | Re: Shaky coding for vacuuming partitioned relations |