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 us
On Wed, Dec 29, 2010 at 3:34 PM, Bruce Momjian 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 t
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.
> >
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
Tom Lane wrote:
> Jeff Janes 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.
>
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 wil
On Fri, Dec 10, 2010 at 8:09 PM, 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.
>>
>> S
> 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, l
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 d
* 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 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
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 do
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 b
On Fri, 2010-12-10 at 07:38 -0500, Robert Haas wrote:
> On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
> 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 sto
> 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, l
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,
On Fri, Dec 10, 2010 at 3:13 PM, Joshua D. Drake 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 to find the logically
>> 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 6:08 PM, Josh Berkus 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 page images.
Th
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 m
> 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
Jeff Janes 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 sequential *isn'
On Fri, Dec 10, 2010 at 12:21 PM, Daniel Loureiro 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.
>
>>The fac
>> 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
Robert Haas writes:
> On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
> 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
On Fri, Dec 10, 2010 at 1:39 AM, Vaibhav Kaushal
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.
>
> This came sudden
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.
Considerin
27 matches
Mail list logo
