On Thu, Jul 23, 2015 at 11:44 AM, Peter Geoghegan wrote:
> If no one weighs in after a few days, I'll mark the patch "rejected"
> in the CF app.
The patch has been marked "rejected" in the CF app. I withdraw it.
Obviously I still think that the patch is worthwhile, but not if that
"while" is dis
2015-07-24 Nicolas Barbier :
> Especially useful would be to know whether interleaving a small number
> of TID ordered streams (as would probably be generated by parallel
> scans/processing) would result in an ordering that performs
> significantly worse or not. I assume (but cannot prove) that in
2015-07-23 Robert Haas :
> I think what you should do is go find out whether the second rationale
> is valid or not.
Knowing how much impact on performance such “non TID ordered” entries
have, would of course be very useful for future patch authors to know.
Especially useful would be to know whet
On Thu, Jul 23, 2015 at 11:28 AM, Robert Haas wrote:
> If other people feel strongly about this issue, then they can weigh in
> and we'll see where we end up. If they don't, then there's no
> consensus to proceed with this, and we shouldn't *have* to spend a lot
> of time on it.
If no one weighs
On Thu, Jul 23, 2015 at 2:19 PM, Peter Geoghegan wrote:
> Our priorities are different, but mine are changing; I simply don't
> want to spend a lot of time arguing with you about things like this.
Good.
If other people feel strongly about this issue, then they can weigh in
and we'll see where we
On Thu, Jul 23, 2015 at 8:19 AM, Robert Haas wrote:
> My priorities are different from yours. Your conclusion is basically
> that it's OK to burden everyone who comes along and does future
> development that may use the sorting code differently from the way
> it's used now with dealing with this i
On Wed, Jul 22, 2015 at 3:17 PM, Peter Geoghegan wrote:
>>> I have a hard time imagining anything (beyond synchronous scans)
>>> breaking my assumption that index tuplesorts receive tuples in heap
>>> physical order. If anything was to break that in the future (e.g.
>>> parallelizing the heap scan
On Wed, Jul 22, 2015 at 11:03 AM, Robert Haas wrote:
>> I'm not concerned about synchronized scans breaking my assumption of a
>> physical ordering of heaptuples being fed to tuplesort.c. I think that
>> it is unlikely to ever be worth seriously considering this case.
>
> Why not?
The case for do
On Tue, Jul 21, 2015 at 4:06 PM, Peter Geoghegan wrote:
> Design considerations and consequences
>
Good write-up.
> I'm not concerned about synchronized scans breaking my assumption of a
> physical ordering of heaptuples being fed to tuple
I have one more idea for accelerating sorting-related operations that
is both fairly effective and relatively easy to implement. This just
about clears my backlog of those, though.
There is an open item on the TODO list entitled "Consider whether
duplicate keys should be sorted by block/offset" [1
10 matches
Mail list logo
