Il 21/06/2010 04:25, Tom Lane ha scritto:
No. You could do that if the rate at which you need to write data to
the file is= the rate at which you extract it. But for what we
are doing, namely merging runs from several tapes into one output run,
it's pretty much guaranteed that you need new
mac_man2...@hotmail.it mac_man2...@hotmail.it writes:
Of course, in this case, output blocks should be placed in the free
space spread around the various files and we should keep track of this
placement.
And once you've done that, what benefit have you got over the current
design? None that
Tom, you are right: it is just more complicated.
In fact, I did not pretend to demonstrate that it was easier or faster
using one file per tape.
As you can remember, I just did not understand why you said it was
*impossible* to recycle space in that case.
So, the conclusion is: you can do
On Sat, Jun 19, 2010 at 4:57 AM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Tom, Robert,
thank you.
Now it is clearer how space on tapes is recycled.
I tried to follow Robert's example but storing one tape per separate file.
Read in the first block of each run (hosted by separate
Robert, so in my example:
- tapes are stored in different files (one tape per file)
- you confirm those first blocks are garbage
- you confirm they could be rewritten with new data
This means that we can do recycle space using one tape per file. Correct?
So, in this case, why do we need to use
mac_man2...@hotmail.it mac_man2...@hotmail.it writes:
Robert, so in my example:
- tapes are stored in different files (one tape per file)
- you confirm those first blocks are garbage
- you confirm they could be rewritten with new data
This means that we can do recycle space using one tape
Tom, Robert,
thank you.
Now it is clearer how space on tapes is recycled.
I tried to follow Robert's example but storing one tape per separate file.
Read in the first block of each run (hosted by separate tapes and so by
separate files) and output them into extra storage, wherever this extra
Hi to all.
Please take a look at the initial comment contained into the logtape.c file:
http://doxygen.postgresql.org/logtape_8c-source.html
Almost at the beginning of that file, it is affirmed that implementing
tapes on disk (quote: /by creating a separate file for each tape/)
will require
On Fri, Jun 18, 2010 at 2:36 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Please take a look at the initial comment contained into the logtape.c file:
http://doxygen.postgresql.org/logtape_8c-source.html
Almost at the beginning of that file, it is affirmed that implementing tapes
Il 18/06/2010 21:00, Robert Haas ha scritto:
On Fri, Jun 18
Did you read the rest of the comment? It explains how the code avoids this...
Robert, thanks for your reply.
I read the rest of the document, but please take in account that my
question wasn't about avoiding.
My question is in
On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Il 18/06/2010 21:00, Robert Haas ha scritto:
On Fri, Jun 18
Did you read the rest of the comment? It explains how the code avoids
this...
Robert, thanks for your reply.
I read the rest of the document,
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 18, 2010 at 3:11 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
I repeat my question. Tuplesort.c and logtape.c DO implement tapes on disk
and currently they do not request 2x or 4x of the input space: so, again, in
which case
Ok, so let's try asking the question in another way.
Which is the difference between having more than one tape into a file
and having one tape per file?
I mean, we are peaking runs belonging to different tapes and merge those
runs.
Moreover, why space is reduced taking in account that we can
On Fri, Jun 18, 2010 at 3:46 PM, mac_man2...@hotmail.it
mac_man2...@hotmail.it wrote:
Which is the difference between having more than one tape into a file and
having one tape per file?
It makes it easier to recycle space a little at a time. Suppose
you're merging two runs of 100 blocks each.
14 matches
Mail list logo
