Re: 2WRS

Mac :)

Suele suceder que despues de casi 20 an#os de desarrollar para
postgresql muchos del core se ponen duros con los recien llegados.

Lo que te sugiero es que no te dejes estar y desarrolles un patch,
directamente enviando el patch cuando te sientas confidente como para
defenderlo. Contra lo empiricamente verdadero no hay mucha refutacion,
decia un profesor amigo.

Estas en la tierra de la colaboracion, pero la colaboracion debe ser
tangible. Lo que muchas veces observo en estas listas, sobre todo en
pgsql-hackers es que no reciben bien las propuestas, pero si discuten
parches, y asi han avanzado varios.

Puntualmente en pgsql-es-ayuda hay algunos que colaboran en
pgsql-hackers. En mi caso soy un asiduo lector y analista del codigo
del motor, conozco humildemente un poco del tema, pero sinceramente
no creo que te pueda ayudar mucho, reconozco que me da fiaca
comprender el nuevo algoritmo que propones y no tendria el tiempo
suficiente creo.

Sin embargo, si te puedo ayudar en algo y queres escribir en privado,
sentite libre de hacerlo.

Te mando un saludo, y que no decaiga!

Guido Barosio

2008/2/3 <mac_man2005(at)hotmail(dot)it>:
> Hola Marcelo.
>
> Muchas gracias por contestar. Te lo agradezco mucho ya que casi nadie suele
> opinar acerca de ese proyecto. Todo el mundo opina sobre "como se usa eso" o
> "como se usa el otro" pero de "internals" ni hablar... bueno... por lo menos
> por lo que concierne ese proyecto.
>
> A parte de criticas. El problema que me encuentro ahora es muy concreto:
>
> como puedo memorizar la posición de la primera y ultima tupla de un run al
> interno de un cierto tape? Eso se debería de hacer durante la fase de
> creación de los runs al fin de permitirme de mover runs de un tape al otro.
>
> Estuve persiguiendo las funciones de "writing" a partir de LogicalTapeWrite
> y me he perdido entre el mogollón de buffers utilizados antes de escribir
> efectivamente en disco duro.
> Mi pregunta es si hay una manera correcta y eficiente de memorizar ese tipo
> de información.
>
> "Supongo" se debería de usar algunos de los campos de la estructura
> "BufFile" (tal y como he puesto en mi ultimo post titulado "Posición de los
> runs en los Tapes"), pero me gastaría conocer lo que opina la gente de esta
> lista de correo al respecto.
>
> De nuevo gracias por tu atención.
>
> Saludos!
>
>
> --------------------------------------------------
> From: "marcelo Cortez" <jmdc_marcelo(at)yahoo(dot)com(dot)ar>
> Sent: Sunday, February 03, 2008 1:26 AM
> To: <mac_man2005(at)hotmail(dot)it>; <pgsql-es-ayuda(at)postgresql(dot)org>
> Subject: Re: [pgsql-es-ayuda] 2WRS
>
>
> > Hola Gente
> >
> >
> > mac_man2005, me parecio reinteresante tu proyecto, no
> > soy un experto como el que andas necesitando ,hice
> > alguno programas en C ,para mis aplicaciones pero nada
> > cerca del kernel del postgres,me gustaria poder ayudar
> > pero no se si mi skill es suficiente, igual un saludo
> > , go postgres!! .
> >
> > MDC
> > --- mac_man2005(at)hotmail(dot)it escribió:
> >
> >> 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
> >>
> >> En un inicio se iba a modificar básicamente solo el
> >> código de la parte de creación de los runs, que
> >> corresponde actualmente al algoritmo Replacement
> >> Selection de Knuth. Por encima la idea era partir la
> >> memoria en dos heaps en vez que uno solo. De eso el
> >> nombre Two-Way Replacement Selection (2WRS) de mi
> >> técnica. Cada heap crea su run físico
> >> correspondiente, pero el punto es que esos dos runs
> >> son relacionados entre si de manera que se pueden
> >> considerar como dos partes diferentes y separadas
> >> ("disjoint") de la misma entidad, la que llamamos
> >> "run lógico".
> >>
> >> 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.
> >>
> >> Muchas gracias por vuestro tiempo.
> >> Un saludo.
> >
> >
> >
> > Tarjeta de crédito Yahoo! de Banco Supervielle.
> > Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa.
> > www.tuprimeratarjeta.com.ar
> > --
> > TIP 5: ¿Has leído nuestro extenso FAQ?
> > http://www.postgresql.org/docs/faqs.FAQ.html
> >
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
>

--
Guido Barosio
-----------------------
http://www.globant.com
guido(dot)barosio(at)globant(dot)com