Robert Treat wrote:
What _is_ interesting is that Postgres often has sequential and
random/disk ways of doing things, and by reducing random_page_cost when
using SSDs, you automatically use more random operations, so in a way
the Postgres code was already prepared for SSD usage.
Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com writes:
Of course if you do a full table scan because their are no better
options, then it scans sequentially. But you have to scan the pages
in *some* order, and it is hard to see how something other than
sequential would be systematically
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a
Bruce Momjian wrote:
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it.
On Wed, Dec 29, 2010 at 3:34 PM, Bruce Momjian br...@momjian.us wrote:
Bruce Momjian wrote:
Vaibhav Kaushal wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be
loureir...@gmail.com (Daniel Loureiro) writes:
You can believe whatever you want, that doesn't make it true.
completely agree. Like yours, Its just my point of view, not the reality.
I agree with some points here, but I wondering how many good ideas are
killed with the thought: this will be a
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a demo comparison. I don't
You can believe whatever you want, that doesn't make it true.
completely agree. Like yours, Its just my point of view, not the reality.
I agree with most points here, but I wondering how many good ideas are
killed with the thought: this will be a performance killer with so
many random access,
On Fri, Dec 10, 2010 at 8:09 PM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
Robert Haas robertmh...@gmail.com writes:
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
disk.
The fact that it's called md.c is a hangover from the '80s. These days,
the
On Fri, Dec 10, 2010 at 12:21 PM, Daniel Loureiro loureir...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
disk.
Jeff Janes jeff.ja...@gmail.com writes:
Of course if you do a full table scan because their are no better
options, then it scans sequentially. But you have to scan the pages
in *some* order, and it is hard to see how something other than
sequential would be systematically better.
In fact, if
I believe that PostgreSQL was been developed and optimized for
sequential access. To get full advantage of SSDs its necessary to
rewrite almost the whole project - there are so much code written with
the sequential mechanism in mind.
You can believe whatever you want, that doesn't make it
On Fri, 2010-12-10 at 15:08 -0800, Josh Berkus wrote:
I believe that PostgreSQL was been developed and optimized for
sequential access. To get full advantage of SSDs its necessary to
rewrite almost the whole project - there are so much code written with
the sequential mechanism in mind.
On Fri, Dec 10, 2010 at 6:08 PM, Josh Berkus j...@agliodbs.com wrote:
Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
which is an in-memory database. Even for a pure-RAM database, it turns
out that just using linked lists and 100% random access is slower than
accessing
Heck, even RAM isn't 1.0. I'm also involved with the Redis project,
which is an in-memory database. Even for a pure-RAM database, it turns
out that just using linked lists and 100% random access is slower than
accessing page images.
That's a slightly different problem, though.
On Fri, Dec 10, 2010 at 3:13 PM, Joshua D. Drake j...@commandprompt.com wrote:
Actually, the only (that I know of) optimized for sequential access code
we have would be for the xlogs.
And even that is more of a book-keeping simplification, rather than an
optimization.
You have to know where
On 10.12.2010 21:21, Daniel Loureiro wrote:
The fact that it's called md.c is a hangover from the '80s. These days,
the logic that the Berkeley guys envisioned being at that code level
is generally in kernel device drivers. md.c can drive anything that
behaves as a block device + filesystem,
You can believe whatever you want, that doesn't make it true.
completely agree. Like yours, Its just my point of view, not the reality.
I agree with some points here, but I wondering how many good ideas are
killed with the thought: this will be a performance killer with so
many random access,
On Fri, 2010-12-10 at 07:38 -0500, Robert Haas wrote:
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
vaibhavkaushal...@gmail.com wrote:
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a demo comparison. I don't
believe that SSDs make quicksort-on-disk feasible, but would be
On Fri, 2010-12-10 at 18:07 -0800, Josh Berkus wrote:
On 12/10/10 5:06 PM, Daniel Loureiro wrote:
An quicksort method in
sequential disk its just awful to be thinking in a non SSD world, but
its possible in an SSD.
So, code it. Shouldn't be hard to write a demo comparison. I don't
On Fri, 2010-12-10 at 23:19 -0500, Stephen Frost wrote:
* Vaibhav Kaushal (vaibhavkaushal...@gmail.com) wrote:
I would like to do that (coding), but I do not have a SSD on my
machine! :( Would it be impractical to try it for me? Again I do not
know how to test PG :(
No, it's not a
* Vaibhav Kaushal (vaibhavkaushal...@gmail.com) wrote:
I would like to do that (coding), but I do not have a SSD on my
machine! :( Would it be impractical to try it for me? Again I do not
know how to test PG :(
No, it's not a trivial amount of work. Perhaps someone will be curious
enough to
Hi all,
Most of you already know I am new to this list and newer to any OSS
development. However, while browsing the source code (of 9.0.1) I find
that there is only one way to store relations on disk - the magnetic
disk.
This came suddenly in my mind so I am asking the experts here.
27 matches
Mail list logo
