Re: 2WRS

2008/1/31 <mac_man2005(at)hotmail(dot)it>:
>
> Hola a todos.
>
> Estoy desarrollando un trabajo de tesis que acabará integrando mi
> "refinement" dentro del código de PostgreSQL. Ese trabajo consiste en
> modificar el algoritmo de External Sorting actualmente implementado en
>
> src/backend/utils/sort/tuplesort.c
>
[...]
>
> La idea es demostrar que el run lógico producido por 2WRS es mas largo que
> el run normal y corriente producido hasta la fecha por el RS. Eso implicaría
> tener un numero de runs menor por fundir y de consecuencia aceleraría esa
> fase de fusión.
>
> El objetivo de este mail es buscar a gente que esté interesada al tema, para
> posiblemente proporcionar mas detalles sobre la técnica y posiblemente
> mejorarla. También agradecería ayuda con solucionar algunos problemas de
> integración. No soy muy experto con el código de PostgreSQL y me gustaría
> aprovechar de la experiencia de alguien mas experto que haya trabajado en
> ello.
>
> Me limito con hacer esa premisa al tema en la espera de que alguien se
> muestre interesado, ya que muchísimas veces he hablado de eso por todos
> lados (mailing list postgres-hackers, #postgres channel en irc.freenode.net
> etc.) y después haberlo explicado todo con muchísimos detalles me han dicho
> que no me iban a poder ayudar.
>

Quiza demasiados detalles, por ejemplo hablabas sobre tu codigo solo
para decir despues que eso no era la mejora...
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01033.php

El problema principal te lo hicieron notar Tom, Simon, Gregory y Sam Mason

Tom (http://archives.postgresql.org/pgsql-hackers/2007-11/msg01055.php)
The discussion from that time period in pgsql-hackers makes it sound
like you need a large test case to notice the problem, though.

Simon (http://archives.postgresql.org/pgsql-hackers/2007-11/msg01120.php)
If you really think it will be better, try it. You'll learn loads, right
or wrong. It's difficult to forecast ahead of time what's a good idea
and what's a bad idea. The real truth of these things is that you need
to pop the hood and start tinkering and its's quite hard to make a plan
for that. If you have a bad idea, just move on to the next one; they're
just ideas.

Gregory (http://archives.postgresql.org/pgsql-hackers/2007-12/msg00007.php)
Seriously, please try a bit harder before giving up.

Sam Mason (http://archives.postgresql.org/pgsql-hackers/2008-01/msg00867.php)
What does your current code look like and how have you solved it there?
If you've already written it then you'll need to be much more specific
with your questions about integrating it into PG.

Basicamente, que debes probar que lo que dices tiene fundamento y para
eso debes primero programarlo y mostrar el código y/o pruebas que
demuestren la mejora... pero preguntar donde debes programarlo y como
debes programarlo y que te expliquen en detalle tuplesort.c no es la
manera de lograr ayuda en -hackers (especialmente porque no produce
confianza en que en realidad estes programando algo) y menos aun
cuando el equipo de desarrollo estaba velando porque 8.3 salga por
fin...

De hecho Simon dijo tener una idea similar a la que expusiste aqui:
http://archives.postgresql.org/pgsql-hackers/2007-11/msg01081.php

Hay codigo escrito puedes publicarlo? si puedes hacerlo muestralo en
patches marcado como [WIP] es mas probable que recibas ayuda asi

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook