[GENERAL] Pg COnference: Call for Lightning Talks

While recently seeking feedback on the conference schedule from Josh
Berkus and David Fetter I was asked, "Are there going to be lightning
talks?". To which I replied, "What?".

I know of lightning talks; in a similar manage of how I know of the
existence of competitors to PostgreSQL. They are there in the
background fog of consciousness while posing no perceivable threat but
still trying to maintain their significance.

The threat here of course is that West won't have lightning talks. So
let's solve that threat now! Enter the call for lightning talks.
Lightning talks are 5 minute, micro talks on any topic of any regard as
long as it is somehow related to PostgreSQL (Pythoners I am calling to
you). If you have something you are willing to stand in front of people
for no more than 5 minutes (or you will be gonged) and talk about this
is your chance.

http://www.pgcon.us/west08/talk_submission/

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[pgsql-advocacy] Pg Conference: Call for Lightning talks

While recently seeking feedback on the conference schedule from Josh
Berkus and David Fetter I was asked, "Are there going to be lightning
talks?". To which I replied, "What?".

I know of lightning talks; in a similar manage of how I know of the
existence of competitors to PostgreSQL. They are there in the
background fog of consciousness while posing no perceivable threat but
still trying to maintain their significance.

The threat here of course is that West won't have lightning talks. So
let's solve that threat now! Enter the call for lightning talks.
Lightning talks are 5 minute, micro talks on any topic of any regard as
long as it is somehow related to PostgreSQL (Pythoners I am calling to
you). If you have something you are willing to stand in front of people
for no more than 5 minutes (or you will be gonged) and talk about this
is your chance.

http://www.pgcon.us/west08/talk_submission/

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

[pgus-general] Pg Conference: Call for Lightning Talks

While recently seeking feedback on the conference schedule from Josh
Berkus and David Fetter I was asked, "Are there going to be lightning
talks?". To which I replied, "What?".

I know of lightning talks; in a similar manage of how I know of the
existence of competitors to PostgreSQL. They are there in the
background fog of consciousness while posing no perceivable threat but
still trying to maintain their significance.

The threat here of course is that West won't have lightning talks. So
let's solve that threat now! Enter the call for lightning talks.
Lightning talks are 5 minute, micro talks on any topic of any regard as
long as it is somehow related to PostgreSQL (Pythoners I am calling to
you). If you have something you are willing to stand in front of people
for no more than 5 minutes (or you will be gonged) and talk about this
is your chance.

http://www.pgcon.us/west08/talk_submission/

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

--
Sent via pgus-general mailing list (pgus-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgus-general

[ODBC] compiling odbc

I am attempting to compile and install psqlodbc-08.03.0200 on my Mac Pro running Leopard.

Here is what I get:

client-66-xxx-17-x14:psqlodbc-08.03.0200 brent1a$ sudo ./configure

checking for a BSD-compatible install... /usr/bin/install -c

checking whether build environment is sane... yes

checking for gawk... no

checking for mawk... no

checking for nawk... no

checking for awk... awk

checking whether make sets $(MAKE)... yes

checking whether to enable maintainer-specific portions of Makefiles... no

checking for pg_config... no

configure: error: pg_config not found (set PG_CONFIG environment variable)

How do I fix "configure: error: pg_config not found (set PG_CONFIG environment variable)"

(I'm relatively new to most of this?

thanks

-B

Re: [pgsql-es-ayuda] Hola

Hola gente

--- El jue 18-sep-08, Gunnar Wolf <gwolf@gwolf.org> escribió:

> De: Gunnar Wolf <gwolf@gwolf.org>
> Asunto: Re: [pgsql-es-ayuda] Hola
> Para: "marcelo Cortez" <jmdc_marcelo@yahoo.com.ar>
> Cc: pgsql-es-ayuda@postgresql.org, "Danier Marante Jacas" <djacas@estudiantes.uci.cu>
> Fecha: jueves, 18 de septiembre de 2008, 1:50 pm
> marcelo Cortez dijo [Wed, Sep 17, 2008 at 10:33:15AM -0700]:
> > Hola
> >
> > Para mi el tema de las bases de datos de objetos y los
> otros metodos de mapear objetos tiene un eje de diferencia
> muy grande y conceptual
> > que termina siendo por donde pasa todo. la identidad.
> > En el paradigmade objetos esta asegurada la identidad
> todo objeto es identico a si mismo y esa identidad es
> unica,( perdon por la redundancia).
> > (...)
> > la diferencia entre mapear en una base de objetos y
> una base relacional es como si por ejemplo ,
> > todas las mañanas tomara mi auto para ir al trabajo y
> luego al llegar a casa lo desarmo todo en cajitas numeradas
> y a la mañana siguiente lo volviera a ensamblar y asi ...
> siempre ...
> > Volviendo al tema , creo que el pivot esta en la
> identidad.
>
> No exactamente. Todo objeto en un lenguaje limpiamente OO
> tiene
> también un ID. Veamos el siguiente ejemplo, en Ruby

Si pero yo me referia a que en una base de objetos no hace falta ni tiene sentido un id.
dije bien , no tiene el menor sentido. pero claro eso es dificil de digerir :( .
Lo que pasa es que los que conocemos como objetos en verdad son aproximaciones, en objetos verdaderos deberiamos hacermos la pregunta, de que clase seria el id ?..

Tampoco tienen sentido las validaciones, porque?

tengo un combobox o cualquier otra forma de presentacion de la informacion, por ejemplo seleccione una calle ...

Cuando eligen una y me devuelve el "resultado" lo que obtengo es una calle.

no un string. que sentido tiene preguntar ,,, es una callle?
tiene altura? que localidad?

no lo tiene porque YA ES .., es una calle.

del mismo modo los objetos no disponen de un campo id. en los ambientes de objetos los objetos no exponen su "id" lo tienen dentro de ellos es posible preguntar por algo "similar" al id pero en gral tiene poco sentido.
salvo en casos muy particulares y para las bases donde estos objetos se guardan no , no necesitan eso.

en las bases relacionales o sistemas de mapeos la UNICA manera de que no se desarme todo es usar el id , tiene un costo..

Hay que administrarlo.. para mi esto responde mas a razones historicas que verdaderas necesidades, en verdad crean mas problemas de los que solucionan OJO hablo del punto de vista de los objetos mapeos y bases de objetos ... desde este punto de vista lo digo.
Grandes problemas de ingenieria trae aparejado esto , y vuelvo a repetir
en objetos..

Para saber si hablamos de lo mismo cuando hablamos de objetos deberiamos ser capaces de responder estas sencillas preguntas todas afirmativamente para poder decir .. SI! es de objetos..

a) es la clase un objeto ?
b) son los procesos un objeto?
c) son los numeros objetos?
d) son todos objetos??

a) es re importante pero no me extendere sobbre ello.
b) c) son solo ejemplos de d) que es el meollo de la situacion.
leer d) pero afirmando , SI SON TODOS OBJETOS!!

si responde a todo eso si
Congratulaciones !!!! ud si esta hablando de objetos!!! :)

saludos a todos

mdc

para los amantes de los links
http://en.wikipedia.org/wiki/Gemstone_Database_Management_System
http://workshop99.ircache.net/Papers/rodriguez-abstract.html

> (estoy usando la
> consola interactiva, irb):
>
> Vamos a crear dos objetos con información aparentemente
> idéntica:
>
> >> cadena1 = "una cadena"
> => "una cadena"
> >> cadena2 = "una cadena"
> => "una cadena"
>
> Verificamos si, a nivel comparación, son iguales:
>
> >> cadena1 == cadena2
> => true
>
> Y vemos sus respectivos IDs:
>
> >> cadena1.object_id
> => 69996972347440
> >> cadena2.object_id
> => 69996972340800
>
> Entonces, claramente, estos dos objetos son iguales, mas no
> son el
> mismo objeto.
>
> ¿Cómo puedo hablar de lo mismo en un modelo
> relacional como el de
> PostgreSQL?
>
> Voy a crear una tabla muy sencilla, con solamente una
> columna, y
> poblarla de datos del mismo modo:
>
> test=# CREATE TEMP table cadena (datos text);
> CREATE TABLE
>
> solserv_test=# INSERT INTO cadena (datos) VALUES ('una
> cadena');
> INSERT 0 1
> solserv_test=# INSERT INTO cadena (datos) VALUES ('una
> cadena');
> INSERT 0 1
>
> Si consulto esta tabla, tengo -del mismo modo que en el
> ejemplo
> anterior- dos registros independientes, aunque casualmente
> idénticos
> (cosa que, obviamente, no quieres ver en una BD de
> producción ;-)
>
> test=# SELECT * from cadena;
> datos
> ------------
> una cadena
> una cadena
> (2 rows)
>
> No me meto en este momento en más detalles - Cada
> registro sigue
> siendo únic, tiene un identificador interno, tan interno
> como el
> object_id de Ruby (que en realidad no es muy utilizable
> más que para
> propósitos demostrativos para el usuario común).
>
> --
> Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 /
> 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5
> 27AF

Yahoo! Cocina
Recetas prácticas y comida saludable
http://ar.mujer.yahoo.com/cocina/
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [ADMIN] Help request: how to tune performance?

Hi,

The only other thing to check is what indexes are defined for
your schema. You can look at a previous post about PostgreSQL
indexing for RT to see what we are using here at Rice. Let me
know if you have any questions.

Cheers,
Ken

On Thu, Sep 18, 2008 at 09:00:14PM +0300, Mauri Sahlberg wrote:
> Hi,
>
> Thanks for the reply and advice.
>
> Scott Marlowe kirjoitti:
>>> Version : 8.1.11 Vendor: CentOS
>>>
>>
>> So, you built it its own machine, but you didn't upgrade to at least 8.2?
>>
>>
> Now it is: 8.4devel_15092008
>
> The machine was installed by the production team from the standard CentOS
> template. I tried to adhere to the standard and installed the standard
> CentOS binary for Postgresql. I am not part of production team so I try to
> be extra careful with the "rule book".
>>
>> Please post the output of explain analyze as an attachment. explain
>> is only half the answer.
>>
>>
> I did what Kenneth Marshall suggested and edited DBIx::Searchbuilder's
> Handle/Pg.pm. I will post the explain analyze for the new query it now
> generates if it becomes necessary.
>> Possibly. explain analyze will help you identify where stats are
>> wrong. sometimes just cranking the stats target on a few columns and
>> re-analyzing gets you a noticeable performance boost. It's cheap and
>> easy.
>>
>> When the estimated and actual number of rows are fairly close, then
>> look for the slowest thing and see if an index can help.
>>
>> What have to already done to tune the install? shared_buffers,
>> work_mem, random_page_cost, effective_cache_size. Is your db bloating
>> during the day?
>>
>>
> When I upgraded to 8.4 I also checked newer Postgresql manual for the
> memory consumption and found comment by Steven Citron-Pousty and increased
> accordingly:
> - shared_buffers to 320MB
> - wal_buffers to 8MB
> - effective_cache_size to 2048MB
> - maintenance_work_mem to 384MB
>
> Sorry, I do not understand what you mean by bloating. The db size is:
> rt=# select pg_size_pretty(pg_database_size('rt'));
> pg_size_pretty
> ----------------
> 350 MB
> (1 row)
>
>> Are you running on a single SATA hard drive? How big's the database
>> directory? I'm guessing from your top output that the db is about 500
>> meg or so. it should all fit in memory.
>>
>>
> -bash-3.2$ du --si -s data
> 524M data
>
> I don't know what kind of drives there actually are. The machine is vmware
> virtual with two virtual CPU's clocking 2,33GHz, 4 GB ram, 1 GB swap. The
> disk is probably given from either MSA or from EVA. The disk shows up as
> one virtual drive and everything is on it. Filesystem is ext3 on lvm.
> Database data is on /var which is it's own volume.
>
> I have also added 5 more mason processes to the web frontend machine.
>
> For me the results look promising. Opening search builder went from 42
> seconds to 4 seconds and opening one particular long chain takes now only
> 27 seconds. But again I am not from the support team either so I do not get
> to define what is fast enough. The verdict is now in for the jury to
> decide.
>
> Thank you.
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [HACKERS] FSM patch - performance test

Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Zdenek Kotala wrote:
>>> My conclusion is that new implementation is about 8% slower in OLTP
>>> workload.
>
>> Thanks. That's very disappointing :-(
>
> One thing that jumped out at me is that you call FreeSpaceMapExtendRel
> every time a rel is extended by even one block. I admit I've not
> studied the data structure in any detail yet, but surely most such calls
> end up being a no-op? Seems like some attention to making a fast path
> for that case would be helpful.

Yes, most of those calls end up being no-op. Which is exactly why I
would be surprised if those made any difference. It does call
smgrnblocks(), though, which isn't completely free...

Zdenek, can you say off the top of your head whether the test was I/O
bound or CPU bound? What was the CPU utilization % during the test?

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] New FSM patch

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> No, FANOUT^4 doesn't fit in int, good catch. Actually, FANOUTPOWERS
> table doesn't need to go that far, so that's just a leftover. It only
> needs to have DEPTH elements. However, we have the same problem if
> DEPTH==3, FANOUT^4 will not fit into int. I put a comment there.
> Ideally, the 4th element would be #iffed out, but I couldn't immediately
> figure out how to do that.

This is a "must fix" IMHO --- I don't plan to tolerate a scary compiler
warning ...

BTW, the comment about and computation of DEPTH are wrong anyway.
We support up to 2^32-1 pages, so I think the cutoff should be 1626.

I did a bit of testing and immediately got an Assert failure:

regression=# create table foo as select x from generate_series(1,100000) x;
SELECT
regression=# create index fooi on foo(x);
CREATE INDEX
regression=# delete from foo;
DELETE 100000
regression=# vacuum foo;
VACUUM
regression=# vacuum foo;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

The reason is that the Assert in FSM_CATEGORY_AVAIL is failing:
TRAP: FailedAssertion("!(x < 8192)", File: "freespace.c", Line: 46)
LOG: server process (PID 17691) was terminated by signal 6: Aborted

because RecordFreeIndexPage passes in BLCKSZ which is an illegal
value. Maybe use BLCKSZ-1 instead?

The scary part of that is that it gets through the regression tests ---
doesn't leave one with a warm feeling about how much of VACUUM gets
exercised by regression.

I take it the comment at the top of indexfsm.c about using one bit per
page should be recast as a possible future improvement?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [ADMIN] Help request: how to tune performance?

Hi,

Thanks for the reply and advice.

Scott Marlowe kirjoitti:
>> Version : 8.1.11 Vendor: CentOS
>>
>
> So, you built it its own machine, but you didn't upgrade to at least 8.2?
>
>
Now it is: 8.4devel_15092008

The machine was installed by the production team from the standard
CentOS template. I tried to adhere to the standard and installed the
standard CentOS binary for Postgresql. I am not part of production team
so I try to be extra careful with the "rule book".
>
> Please post the output of explain analyze as an attachment. explain
> is only half the answer.
>
>
I did what Kenneth Marshall suggested and edited DBIx::Searchbuilder's
Handle/Pg.pm. I will post the explain analyze for the new query it now
generates if it becomes necessary.
> Possibly. explain analyze will help you identify where stats are
> wrong. sometimes just cranking the stats target on a few columns and
> re-analyzing gets you a noticeable performance boost. It's cheap and
> easy.
>
> When the estimated and actual number of rows are fairly close, then
> look for the slowest thing and see if an index can help.
>
> What have to already done to tune the install? shared_buffers,
> work_mem, random_page_cost, effective_cache_size. Is your db bloating
> during the day?
>
>
When I upgraded to 8.4 I also checked newer Postgresql manual for the
memory consumption and found comment by Steven Citron-Pousty and
increased accordingly:
- shared_buffers to 320MB
- wal_buffers to 8MB
- effective_cache_size to 2048MB
- maintenance_work_mem to 384MB

Sorry, I do not understand what you mean by bloating. The db size is:
rt=# select pg_size_pretty(pg_database_size('rt'));
pg_size_pretty
----------------
350 MB
(1 row)

> Are you running on a single SATA hard drive? How big's the database
> directory? I'm guessing from your top output that the db is about 500
> meg or so. it should all fit in memory.
>
>
-bash-3.2$ du --si -s data
524M data

I don't know what kind of drives there actually are. The machine is
vmware virtual with two virtual CPU's clocking 2,33GHz, 4 GB ram, 1 GB
swap. The disk is probably given from either MSA or from EVA. The disk
shows up as one virtual drive and everything is on it. Filesystem is
ext3 on lvm. Database data is on /var which is it's own volume.

I have also added 5 more mason processes to the web frontend machine.

For me the results look promising. Opening search builder went from 42
seconds to 4 seconds and opening one particular long chain takes now
only 27 seconds. But again I am not from the support team either so I do
not get to define what is fast enough. The verdict is now in for the
jury to decide.

Thank you.

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [PERFORM] Why does this query write to the disk?

>>> "Nikolas Everett" <nik9000@gmail.com> wrote:

> I'm a bit confused as to why this query writes to the disk:
> SELECT count(*)
> FROM bigbigtable
> WHERE customerid IN (SELECT customerid FROM
> smallcustomertable)
> AND x !=
> 'special'
>
> AND y IS NULL
>
> It writes a whole bunch of data to the disk that has the tablespace
where
> bigbigtable lives as well as writes a little data to the main disk.
It
> looks like its is actually WAL logging these writes.

It's probably writing hint bits to improve performance of subsequent
access to the table. The issue is discussed here:

http://wiki.postgresql.org/wiki/Hint_Bits

-Kevin

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[BUGS] BUG #4425: cannot pg_restore from pg_dump --format=c

The following bug has been logged online:

Bug reference: 4425
Logged by: Kieran McCusker
Email address: kieran.mccusker@kwest.info
PostgreSQL version: 8.3.3
Operating system: Linux (fc9)
Description: cannot pg_restore from pg_dump --format=c
Details:

Hi

I'm trying to copy a database between two servers (both fc9).

If I do the following:-

pg_dump --format=c --username=portal --file=test.dump Portal

Create the database using:-

createdb -E utf8 --owner=portal --template postgres Portal

then:

pg_restore --dbname=Portal test.dump

The database schema is partially restored and no data added.

If I do the same thing using pg_dump --format=p and loading it using psql it
works fine. The database was originally created under fc7 (sorry can't
remember the version) Its a bit worrying as it means the previous nightly
backups are not usable.

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[pgsql-es-ayuda] Problemas con pg_dump, mediawiki y encodings.

Hola, les escribo por un detalle que estamos teniendo a la hora de hacer restauraciones a partir de dumps de una base de datos de MediaWiki con pg_dump en PostgreSQL 8.1.11. Los dumps los hemos realizado tanto en texto plano como comprimidos, pero de ninguna forma hemos podido hacer el restore. El error que surge siempre es similar al siguiente:

ERROR:  secuencia de bytes no válida para codificación «UTF8»: 0x94

Los errores surgen principalmente al insertar datos sobre la tabla mediawiki.text, la cual contiene el código tipo MEDIAWIKI de cada página alojada en la wiki en cuestión.

Al revisar los archivos del dump, se puede observar que la mayoría de los caracteres especiales alojados en él se encuentran con el signo (�). Dentro de la wiki original se pueden ver los caracteres especiales sin ningún problema. Las BDs se encuentran con codificación UTF8, tanto la original, como la que queremos restaurar.

Cualquier ayuda que me puedan dar con respecto a esto será bastante agradecida.

Saludos, Luis Garcia.

--
Luis D. García M.

Telf: (+58) 2418662663
Cel.: (+58) 4143482018

[pgsql-es-ayuda] FW: ayuda

> > hola,
> > estoy instalando postgreSql bajo window Xp pero para ello me piden que instale un poco de componente
> > entre ellos tengo cygwin, cyipc odbc y pgAdmin III.
> > estoy en la consola de cygwin y quiero ejecutar el comando net Start ipc-daemon
> > y me da el siguiente error El servicio no esta respondiendo a la funcion de control
> >
> > Al iniciar el servicio x inicio-panel de control-herramientas administrativas-servicios me da el siguiente error
> > No se puede iniciar el servicio CygwinIPcDaemon en equipo local
> > error 1053> el servidor no ha respondido a la peticion o inicio de control en un tiempo adecuado
> >
> > Otra pregunta si instalo el cygwin, cygipc y odbc estos trabajan en consola y paAdmin con una interfaz como realaciono estos dos
> >
> > ayudenm xfa
> >
> >
> > _________________________________________________________________
> > Discover the new Windows Vista
> > http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---

Connect to the next generation of MSN Messenger  Get it now!

[PERFORM] Why does this query write to the disk?

List,

I'm a bit confused as to why this query writes to the disk:
SELECT count(*)
FROM    bigbigtable
WHERE customerid IN (SELECT customerid FROM smallcustomertable)                                                        
AND x != 'special'                                                                               
AND y IS NULL 

It writes a whole bunch of data to the disk that has the tablespace where bigbigtable lives as well as writes a little data to the main disk.  It looks like its is actually WAL logging these writes.

Here is the EXPLAIN ANALYZE:
Aggregate  (cost=46520194.16..46520194.17 rows=1 width=0) (actual time=4892191.995..4892191.995 rows=1 loops=1)
  ->  Hash IN Join  (cost=58.56..46203644.01 rows=126620058 width=0) (actual time=2.938..4840349.573 rows=79815986 loops=1)
        Hash Cond: ((bigbigtable.customerid)::text = (smallcustomertable.customerid)::text)
        ->  Seq Scan on bigbigtable  (cost=0.00..43987129.60 rows=126688839 width=11) (actual time=0.011..4681248.143 rows=128087340 loops=1)
              Filter: ((y IS NULL) AND ((x)::text <> 'special'::text))
        ->  Hash  (cost=35.47..35.47 rows=1847 width=18) (actual time=2.912..2.912 rows=1847 loops=1)
              ->  Seq Scan on smallcustomertable  (cost=0.00..35.47 rows=1847 width=18) (actual time=0.006..1.301 rows=1847 loops=1)
Total runtime: 4892192.086 ms

Can someone point me to some documentation as to why this writes to disk?

Thanks,
Nik

[GENERAL] Running initdb while logged in as Administrator user (Windows)

I'm trying to develop an automated PostgreSQL installer for Windows that uses a silent install of PostgreSQL and batch scripts to initialise the database cluster (i.e. run initdb) and start/stop the db server. The install shouldn't install as a service, so initdb needs to be run manually.

The problem I'm having is that initdb cannot be run as an Administrator user, so I wrote a script that creates a new limited Windows user and I now want to run initdb using this user, but while still logged in as the Administrator user.
I've looked at using the RUNAS comand, but the user password has to be inserted manually when using this. I've also tried to pipe in the password using echo *** | RUNAS... where *** is the password, but this doesn't seem to work.

I know there are some apps out there that function as alternatives to RUNAS but some of them require licences, and I'm looking for a distributable solution.

How does the PostgreSQL installer work around this when a new limited user can be specified when installing as a service?

Thanks,
Daniel.

Re: [pgsql-es-ayuda] pregutna soporte

2008/9/18 Franz Marin <frarimava@hotmail.com>:
> buenas tardes!
>
> Alvaro cuando me dice que la DB entra en la RAM o no ... no entiendo esa
> parte, que ventajas tiene que entre o no en la RAM y como lo puedo hacer
>

Me parece que se refiere a que el tamaño total de tu db sea menor a la
cantidad de ram que tienes, si es asi todos tus datos podrian alojarse
en ram y las consultas no tendrian que acceder al disco para extraer
los datos, solo cuando moirifaras tus datos se tendria que hacer un
acceso a disco, esto de tener todos tus datos en ram te da un acceso a
los datos mucho mas rapido que accesar a disco :p

--
"Linux is for people who hate Windows, BSD is for people who love UNIX".
"Social Engineer -> Because there is no patch for human stupidity"
"The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ;
mount ; fsck ; more ; yes ; umount ; sleep."
"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."
--
TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
http://archives.postgresql.org/pgsql-es-ayuda

Re: [JDBC] Bad Timestamp Format at 23 in 2008-09-16 18:41:00.479

On Thu, 18 Sep 2008, Warren Bell wrote:

> Caused by: Bad Timestamp Format at 23 in 2008-09-17 19:49:03.327
> at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:517)
> at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:675)
> at

This stacktrace is from a 7.2 or earlier JDBC driver, so you definitely
aren't using 8.3-603.

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [JDBC] Bad Timestamp Format at 23 in 2008-09-16 18:41:00.479

I am using Ibatis as a object mapper and Spring as the DAO. Ibatis
assures me that Ibatis is just passing the parameters strait to the
driver without modifying them. Ibatis is logging the Insert statement as:

DEBUG [http-8080-2] - {conn-100072} Preparing Statement: INSERT
INTO receiveorder (rcv_date, rcv_po_number, rcv_invoice_number,
rcv_vendor_code, rcv_vendor_name, rcv_str_fk, rcv_usr_fk,
rcv_time_changed) values (?, ?, ?, ?, ?, ?, ?, NOW())
DEBUG [http-8080-2] - {pstm-100073} Executing Statement: INSERT
INTO receiveorder (rcv_date, rcv_po_number, rcv_invoice_number,
rcv_vendor_code, rcv_vendor_name, rcv_str_fk, rcv_usr_fk,
rcv_time_changed) values (?, ?, ?, ?, ?, ?, ?, NOW())
DEBUG [http-8080-2] - {pstm-100073} Parameters: [2008-09-17
19:55:44.774, 333, 333, 93 , American Biologics , 1, 3]
DEBUG [http-8080-2] - {pstm-100073} Types: [java.sql.Timestamp,
java.lang.String, java.lang.String, java.lang.String, java.lang.String,
java.lang.Integer, java.lang.Integer]

rcv_date is the field that is causing the problem not the NOW()
function. When this statement in executed from the Apple machine the
timestamp in the db is 2008-09-17 19:55:44.774 and when it is executed
on the Windows machine the timestamp in the db is 2008-09-17 19:55:44.77
. On the Windows machine it looses the last decimal of the milliseconds
from miliseconds to hundreths. When the Windows machine does a SELECT on
the record with the milliseconds it gives me the following exception:

DEBUG [http-8080-1] - {pstm-100294} Executing Statement: SELECT
rcv_pk, rcv_str_fk, rcv_date, rcv_po_number, rcv_invoice_number,
rcv_vendor_code, rcv_vendor_name, rcv_processed, rcv_report, rcv_usr_fk
FROM receiveorder WHERE rcv_processed = ? ORDER BY rcv_date DESC
DEBUG [http-8080-1] - {pstm-100294} Parameters: [false]
DEBUG [http-8080-1] - {pstm-100294} Types: [java.lang.Boolean]

DEBUG [http-8080-1] - {rset-100295} Result: [3737, 1, 2008-09-18
02:35:36.8, 454 , 323 ,
329 , Garden Of Life , false, false, 3, 3737]
org.springframework.jdbc.UncategorizedSQLException: SqlMapClient
operation; uncategorized SQLException for SQL []; SQL state [null];
error code [0];
--- The error occurred in
com/clarks/spanky/persistence/sqlmapdao/sql/postgres/recvOrder-postgres.xml.

--- The error occurred while applying a result map.
--- Check the RecvOrder.recvOrderWithLineItemsResult.
--- Check the result mapping for the 'recvOrderDate' property.
--- Cause: Bad Timestamp Format at 23 in 2008-09-17 19:49:03.327; nested
exception is com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in
com/clarks/spanky/persistence/sqlmapdao/sql/postgres/recvOrder-postgres.xml.

--- The error occurred while applying a result map.
--- Check the RecvOrder.recvOrderWithLineItemsResult.
--- Check the result mapping for the 'recvOrderDate' property.
--- Cause: Bad Timestamp Format at 23 in 2008-09-17 19:49:03.327
at
org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.translate(SQLStateSQLExceptionTranslator.java:121)
at
org.springframework.jdbc.support.SQLErrorCodeSQLExceptionTranslator.translate(SQLErrorCodeSQLExceptionTranslator.java:322)
at
org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:212)
at
org.springframework.orm.ibatis.SqlMapClientTemplate.executeWithListResult(SqlMapClientTemplate.java:249)
at
org.springframework.orm.ibatis.SqlMapClientTemplate.queryForList(SqlMapClientTemplate.java:296)
at
com.clarks.spanky.persistence.sqlmapdao.RecvOrderSqlMapDao.getProcessedRecvOrderListWithLineItems(RecvOrderSqlMapDao.java:49)
at
com.clarks.spanky.service.ReceivingService.getProcessedRecvOrderListWithLineItems(ReceivingService.java:82)
at
com.clarks.spanky.presentation.ReceivingBean.goToOpenedReceivings(ReceivingBean.java:238)
at
com.clarks.spanky.presentation.NavRecvBean.receivingNavigation(NavRecvBean.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.clarks.struts.BeanAction.execute(BeanAction.java:123)
at
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:507)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:856)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:565)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1509)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.ibatis.common.jdbc.exception.NestedSQLException:
--- The error occurred in
com/clarks/spanky/persistence/sqlmapdao/sql/postgres/recvOrder-postgres.xml.

--- The error occurred while applying a result map.
--- Check the RecvOrder.recvOrderWithLineItemsResult.
--- Check the result mapping for the 'recvOrderDate' property.
--- Cause: Bad Timestamp Format at 23 in 2008-09-17 19:49:03.327
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:185)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForList(GeneralStatement.java:123)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:615)
at
com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForList(SqlMapExecutorDelegate.java:589)
at
com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForList(SqlMapSessionImpl.java:118)
at
org.springframework.orm.ibatis.SqlMapClientTemplate$3.doInSqlMapClient(SqlMapClientTemplate.java:298)
at
org.springframework.orm.ibatis.SqlMapClientTemplate.execute(SqlMapClientTemplate.java:209)
... 29 more
Caused by: Bad Timestamp Format at 23 in 2008-09-17 19:49:03.327
at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:517)
at org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:675)
at
org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:262)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
com.ibatis.common.jdbc.logging.ResultSetLogProxy.invoke(ResultSetLogProxy.java:47)
at $Proxy4.getTimestamp(Unknown Source)
at
com.ibatis.sqlmap.engine.type.DateTypeHandler.getResult(DateTypeHandler.java:38)
at
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getPrimitiveResultMappingValue(BasicResultMap.java:611)
at
com.ibatis.sqlmap.engine.mapping.result.BasicResultMap.getResults(BasicResultMap.java:344)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.handleResults(SqlExecutor.java:381)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.handleMultipleResults(SqlExecutor.java:301)
at
com.ibatis.sqlmap.engine.execution.SqlExecutor.executeQuery(SqlExecutor.java:190)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.sqlExecuteQuery(GeneralStatement.java:205)
at
com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryWithCallback(GeneralStatement.java:173)
... 35 more

Kris Jurka wrote:
>
>
> On Wed, 17 Sep 2008, Warren Bell wrote:
>
>> I have Postgresql 8.3 (PostgresPlus) running on an Apple with Tomcat
>> 6. I am using the postgresql-8.3-603.jdbc3.jar driver. My app runs
>> fine when on the apple, but when I move it over to a Windows machine
>> running Tomcat 6 that accesses the same exact database on the Apple I
>> get a "Bad Timestamp Format at 23 in 2008-09-16 18:41:00.479" error.
>
> This isn't an error that the JDBC driver produces. Can you provide a
> stacktrace to show where this error is actually generated?
>
> Kris Jurka

--
Thanks,

Warren Bell
909-645-8864
warren@clarksnutrition.com

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [pgsql-es-ayuda] pregutna soporte

buenas tardes!

Alvaro cuando me dice que la DB entra en la RAM o no ... no entiendo esa
parte, que ventajas tiene que entre o no en la RAM y como lo puedo hacer

--------------------------------------------------
From: "Alvaro Herrera" <alvherre@alvh.no-ip.org>
Sent: Thursday, September 18, 2008 11:55 AM
To: "Franz Marin" <frarimava@hotmail.com>
Cc: "lista de postgres" <pgsql-es-ayuda@postgresql.org>
Subject: Re: [pgsql-es-ayuda] pregutna soporte

> Franz Marin escribió:
>
>> quisiera saber QUE VERSION DE PostgreSQL aprovecharía esta
>> configuración al máximo o mejor
>
> Las versiones más recientes son siempre mejores, debido a mayor
> inteligencia que se le agrega al optimizador de consultas, y a
> optimizaciones en otras partes. En este caso es obvio que debes partir
> de 8.3.
>
> --
> Alvaro Herrera
> http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
> "Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente"
> --
> TIP 2: puedes desuscribirte de todas las listas simultáneamente
> (envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)
>
--
TIP 4: No hagas 'kill -9' a postmaster

Re: [ADMIN] Regaining superuser access

Bernt Drange escribió:

> After a lot of fiddling with being able to enter single user mode on a
> windows machine (I had to figure out how to run the command line as
> the correct user, then for some reason -D didn't work, but SET
> PGDATA=xxx worked), I finally managed to fix my problem.

Hmm, the -D thing not working should probably be studied -- perhaps
we're missing escaping something somewhere. Does the PGDATA path
contain spaces or weird chars?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Re: [pgsql-es-ayuda] pregutna soporte

Franz Marin escribió:

> quisiera saber QUE VERSION DE PostgreSQL aprovecharía esta
> configuración al máximo o mejor

Las versiones más recientes son siempre mejores, debido a mayor
inteligencia que se le agrega al optimizador de consultas, y a
optimizaciones en otras partes. En este caso es obvio que debes partir
de 8.3.

--
Alvaro Herrera http://www.amazon.com/gp/registry/3BP7BYG9PUGI8
"Puedes vivir solo una vez, pero si lo haces bien, una vez es suficiente"
--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

Franz Marin escribió:

> Memoria Ram 2 GB (2 x 1GB) Standard PC2-5300 Fully Buffered DIMMs (DDR2-667)

> MEMORIA 16 GB FBD PC2-5300 (NUEVA GENERACION) $ 1.041 $ 1.041

¿O sea un total de 18 GB de RAM?

> PROLIANT DL360G5 (1) Quad-Core Intel® Xeon® E5430 Processor (2.66 GHz, 80 Watts, 1333 FSB) Memoria Cache 12MB (2 x 6MB) Level 2 cache
> 1 PROCESADOR Xeon Quad-Core E5430 (2.66 GHz, 80 Watts, 1333 FSB)

¿O sea 8 cores en total? Si la aplicación va a ser OLTP entonces bien,
porque vas a poder atender 8 conexiones concurrentemente sin problemas
(ojo con la limitación que vas a tener dependiendo de la cantidad de
discos; pero si la BD entra en RAM entonces no debería ser una
consideración tan importante). Si la BD no entra en RAM entonces
quizás te convenga quedarte con 4 cores (1 CPU) y poner más discos y/o
más RAM, pero es relativo.

> 6 DISCO DURO 146GB 10k SAS 2.5 Hot Plug (NUEVA GENERACION) $ 393 $ 2.360
>
> quisiera saber si PostgreSQL aprovecharía esta configuración al máximo

Probablemente sí (al menos es capaz), pero qué tan bien funcione depende
de varios factores. Por ej. el nivel de RAID en que vayas a poner los
discos; deberías medirlo para tu aplicación, pero creo que lo usual es
que lo óptimo sea RAID 10 (1+0). Ojo que puede ser que más discos de
menor tamaño te pueden dar más rendimiento (pero ojo con las RPM)

Fíjate si tienes espacio para más memoria RAM y discos extra,
dependiendo de qué tan grande vaya a ser la base de datos.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)
--
TIP 8: explain analyze es tu amigo

Re: [pgsql-es-ayuda] Hola

marcelo Cortez dijo [Wed, Sep 17, 2008 at 10:33:15AM -0700]:
> Hola
>
> Para mi el tema de las bases de datos de objetos y los otros metodos de mapear objetos tiene un eje de diferencia muy grande y conceptual
> que termina siendo por donde pasa todo. la identidad.
> En el paradigmade objetos esta asegurada la identidad todo objeto es identico a si mismo y esa identidad es unica,( perdon por la redundancia).
> (...)
> la diferencia entre mapear en una base de objetos y una base relacional es como si por ejemplo ,
> todas las mañanas tomara mi auto para ir al trabajo y luego al llegar a casa lo desarmo todo en cajitas numeradas y a la mañana siguiente lo volviera a ensamblar y asi ... siempre ...
> Volviendo al tema , creo que el pivot esta en la identidad.

No exactamente. Todo objeto en un lenguaje limpiamente OO tiene
también un ID. Veamos el siguiente ejemplo, en Ruby (estoy usando la
consola interactiva, irb):

Vamos a crear dos objetos con información aparentemente idéntica:

>> cadena1 = "una cadena"
=> "una cadena"
>> cadena2 = "una cadena"
=> "una cadena"

Verificamos si, a nivel comparación, son iguales:

>> cadena1 == cadena2
=> true

Y vemos sus respectivos IDs:

>> cadena1.object_id
=> 69996972347440
>> cadena2.object_id
=> 69996972340800

Entonces, claramente, estos dos objetos son iguales, mas no son el
mismo objeto.

¿Cómo puedo hablar de lo mismo en un modelo relacional como el de
PostgreSQL?

Voy a crear una tabla muy sencilla, con solamente una columna, y
poblarla de datos del mismo modo:

test=# CREATE TEMP table cadena (datos text);
CREATE TABLE

solserv_test=# INSERT INTO cadena (datos) VALUES ('una cadena');
INSERT 0 1
solserv_test=# INSERT INTO cadena (datos) VALUES ('una cadena');
INSERT 0 1

Si consulto esta tabla, tengo -del mismo modo que en el ejemplo
anterior- dos registros independientes, aunque casualmente idénticos
(cosa que, obviamente, no quieres ver en una BD de producción ;-)

test=# SELECT * from cadena;
datos
------------
una cadena
una cadena
(2 rows)

No me meto en este momento en más detalles - Cada registro sigue
siendo únic, tiene un identificador interno, tan interno como el
object_id de Ruby (que en realidad no es muy utilizable más que para
propósitos demostrativos para el usuario común).

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [HACKERS] Do we really need a 7.4.22 release now?

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Greg Sabino Mullane wrote:
>> - From a business perspective, there has been no reason to go through the
>> pain and downtime of an upgrade, as long as the PG project is releasing
>> point revisions to the 7.4 branch. As I said, I'm all for getting people
>> off 7.4, but it needs to be done with a definite date, and December is
>> way too soon.

> Specifying an EOL date does not stop people from continuing to run 7.4.
> They can set their own time lines to get off the release. They can also
> pay someone to update the back branch if it is that important to them.

Yeah. What this is about is how long the *community* supports 7.4
(for free, and at the cost of time that might be better spent on
development).

Looking at the CVS logs makes it pretty obvious that we've been
effectively partially desupporting 7.4, and even 8.0 and 8.1 to some
extent, for awhile now. There have been numerous patches that were not
carried all the way back because they would have needed major revisions
for the older branches --- not because the problem didn't exist in some
form or other back then. The community hasn't got the interest or
resources to create such patches, much less to QA them to the level
where a person too conservative to move off an old branch would think
the patches were safe.

It's really past time to make it clear to all concerned that if they
want continued bug fixes for 7.4, they'd better start paying somebody
to do it.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Do we really need a 7.4.22 release now?

On Sep 18, 2008, at 07:38, Tom Lane wrote:

> I wasn't intending to start a discussion about how/when to EOL 7.4,
> but since the thread has gone in that direction: my vote would be to
> announce now (say, with the announcement of this set of releases) that
> 7.4 will be EOL'd with our first set of updates in 2009. That would
> probably be the next update after this one, maybe two updates away
> if we find any really serious bugs in the next month or two.

+1

Best,

David

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] pregutna soporte

Buenos Días!

 

mi pregunta es la siguiente ... vamos a adquirir un servidor con las siguientes características:

 

PROLIANT DL360G5 (1) Quad-Core Intel® Xeon® E5430 Processor (2.66 GHz, 80 Watts, 1333 FSB) Memoria Cache 12MB (2 x 6MB) Level 2 cache

Memoria Ram 2 GB (2 x 1GB) Standard PC2-5300 Fully Buffered DIMMs (DDR2-667)

Controladora de Discos HP Smart Array P400i/256MB Controller (RAID 0/1/1+0/5) 512MB BBWC or BBWC optional upgrades

 MEMORIA 16 GB FBD PC2-5300 (NUEVA GENERACION)

2  PROCESADOR Xeon Quad-Core E5430 (2.66 GHz, 80 Watts, 1333 FSB)

6 DISCOS DUROS 146GB 10k SAS 2.5 Hot Plug (NUEVA GENERACION)

Sistema Operativo Red Hat Enterprise Linux 5 x32 and x64, 1-2 socket, 3yr FI x64, auto-entitle
(420-7441)

quisiera saber QUE VERSION DE  PostgreSQL aprovecharía esta configuración al máximo  o mejor

Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

> que pena el sistema operativo es
>
> Red Hat Enterprise Linux 5 x32 and x64, 1-2 socket, 3yr FI x64, auto-entitle
> (420-7441)
>

No entendi, porque pena ? asi esta mucho mejor que con un windows claquiera.

--
"Linux is for people who hate Windows, BSD is for people who love UNIX".
"Social Engineer -> Because there is no patch for human stupidity"
"The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ;
mount ; fsck ; more ; yes ; umount ; sleep."
"Documentation is like sex: when it is good, it is very, very good;
and when it is bad, it is better than nothing."
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

Franz Marin dijo [Thu, Sep 18, 2008 at 11:12:31AM -0500]:
> Buenos Dias!
>
> mi pregunta es la siguiente ... vamos a adquirir un servidor con las siguientes características:
> (...)
> quisiera saber si PostgreSQL aprovecharía esta configuración al máximo

La pregunta es si tu aplicación lo va a explotar o no. PostgreSQL
es muy poco probable que use algunos de los componentes que mencionas
(como los ventiladores o los slots de expansión).

Saludos,

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [JDBC] Bad Timestamp Format at 23 in 2008-09-16 18:41:00.479

On Wed, 17 Sep 2008, Warren Bell wrote:

> I have Postgresql 8.3 (PostgresPlus) running on an Apple with Tomcat 6. I am
> using the postgresql-8.3-603.jdbc3.jar driver. My app runs fine when on the
> apple, but when I move it over to a Windows machine running Tomcat 6 that
> accesses the same exact database on the Apple I get a "Bad Timestamp Format
> at 23 in 2008-09-16 18:41:00.479" error.

This isn't an error that the JDBC driver produces. Can you provide a
stacktrace to show where this error is actually generated?

Kris Jurka

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

que pena el sistema operativo es

Red Hat Enterprise Linux 5 x32 and x64, 1-2 socket, 3yr FI x64, auto-entitle
(420-7441)

--------------------------------------------------
From: "Moises Alberto Lindo Gutarra" <mlindo@gmail.com>
Sent: Thursday, September 18, 2008 11:20 AM
To: "lista de postgres" <pgsql-es-ayuda@postgresql.org>
Subject: Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

> 2008/9/18 Franz Marin <frarimava@hotmail.com>:
>> Buenos Dias!
>>
>> mi pregunta es la siguiente ... vamos a adquirir un servidor con las
>> siguientes características:
>>
>>
>> PROLIANT DL360G5 (1) Quad-Core Intel(R) Xeon(R) E5430 Processor (2.66
>> GHz, 80
>> Watts, 1333 FSB) Memoria Cache 12MB (2 x 6MB) Level 2 cache
>>
>> Memoria Ram 2 GB (2 x 1GB) Standard PC2-5300 Fully Buffered DIMMs
>> (DDR2-667)
>>
>> Controladora de Discos HP Smart Array P400i/256MB Controller (RAID
>> 0/1/1+0/5) 512MB BBWC or BBWC optional upgrades
>>
>> PCI-Express Slots 1 full-length x8 PCI-Express slot 1 low-profile x8
>> PCI-Express slot
>>
>> Ventildores 9 en total con redundancia standard
>>
>> MEMORIA 16 GB FBD PC2-5300 (NUEVA GENERACION)
>>
>> $ 1.041 $ 1.041
>>
>> 1 PROCESADOR Xeon Quad-Core E5430 (2.66 GHz, 80 Watts, 1333 FSB)
>>
>> 6 DISCO DURO 146GB 10k SAS 2.5 Hot Plug (NUEVA GENERACION)
>>
>> $ 393 $ 2.360
>>
>>
>>
>>
>> quisiera saber si PostgreSQL aprovecharía esta configuración al máximo
>
> Esto va a depender de tu DBA, el SO en el que se monte postgresql y de
> varios
> factores mas, sin embargo me parece bueno el fierro.
>
>
>
> --
> Atentamente,
> Moisés Alberto Lindo Gutarra
> Asesor - Desarrollador Java / Open Source
> Linux Registered User #431131 - http://counter.li.org/
> Cel: (511) 995081720
> MSN: mlindo@tumisolutions.com
> --
> TIP 8: explain analyze es tu amigo
>
--
TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

Re: [HACKERS] Do we really need a 7.4.22 release now?

Hi,

On Thu, 2008-09-18 at 09:20 -0400, Tom Lane wrote:
> So I'm thinking that generating a 7.4.x tarball now would be mostly a
> waste of server space, and we should leave these changes for the next
> update cycle.

How much server space or CPU cycles are we talking about? I bet it is
less than the bytes we spent during this discussion. Only I will build
binaries for 7.4, and you'll push an update for RHEL.

My vote is announcing all releases together, including 7.4 .
--
Devrim GÜNDÜZ, RHCE
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org

Re: [pgsql-es-ayuda] PREGUNTA SOPORTE

2008/9/18 Franz Marin <frarimava@hotmail.com>:
> Buenos Dias!
>
> mi pregunta es la siguiente ... vamos a adquirir un servidor con las
> siguientes características:
>
>
> PROLIANT DL360G5 (1) Quad-Core Intel(R) Xeon(R) E5430 Processor (2.66 GHz, 80
> Watts, 1333 FSB) Memoria Cache 12MB (2 x 6MB) Level 2 cache
>
> Memoria Ram 2 GB (2 x 1GB) Standard PC2-5300 Fully Buffered DIMMs (DDR2-667)
>
> Controladora de Discos HP Smart Array P400i/256MB Controller (RAID
> 0/1/1+0/5) 512MB BBWC or BBWC optional upgrades
>
> PCI-Express Slots 1 full-length x8 PCI-Express slot 1 low-profile x8
> PCI-Express slot
>
> Ventildores 9 en total con redundancia standard
>
> MEMORIA 16 GB FBD PC2-5300 (NUEVA GENERACION)
>
> $ 1.041 $ 1.041
>
> 1 PROCESADOR Xeon Quad-Core E5430 (2.66 GHz, 80 Watts, 1333 FSB)
>
> 6 DISCO DURO 146GB 10k SAS 2.5 Hot Plug (NUEVA GENERACION)
>
> $ 393 $ 2.360
>
>
>
>
> quisiera saber si PostgreSQL aprovecharía esta configuración al máximo

Esto va a depender de tu DBA, el SO en el que se monte postgresql y de varios
factores mas, sin embargo me parece bueno el fierro.

--
Atentamente,
Moisés Alberto Lindo Gutarra
Asesor - Desarrollador Java / Open Source
Linux Registered User #431131 - http://counter.li.org/
Cel: (511) 995081720
MSN: mlindo@tumisolutions.com
--
TIP 8: explain analyze es tu amigo

Re: [HACKERS] FSM patch - performance test

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Zdenek Kotala wrote:
>> My conclusion is that new implementation is about 8% slower in OLTP
>> workload.

> Thanks. That's very disappointing :-(

One thing that jumped out at me is that you call FreeSpaceMapExtendRel
every time a rel is extended by even one block. I admit I've not
studied the data structure in any detail yet, but surely most such calls
end up being a no-op? Seems like some attention to making a fast path
for that case would be helpful.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Do we really need a 7.4.22 release now?

Greg Sabino Mullane wrote:

> - From a business perspective, there has been no reason to go through the
> pain and downtime of an upgrade, as long as the PG project is releasing
> point revisions to the 7.4 branch. As I said, I'm all for getting people
> off 7.4, but it needs to be done with a definite date, and December is
> way too soon.

Specifying an EOL date does not stop people from continuing to run 7.4.
They can set their own time lines to get off the release. They can also
pay someone to update the back branch if it is that important to them.

December 31st is plenty of time. This isn't closed source where with the
big O says no more updates, you are completely hosed.

Sincerely,

Joshua D. Drake

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] optimizing CleanupTempFiles

Alvaro Herrera <alvherre@commandprompt.com> writes:
> Don't temp tables use this kind of temp file? I admit I didn't check; I
> just assumed they did.

No, temp tables go through localbuf.c, which sits atop regular smgr.
I don't think fd.c knows any difference from regular tables.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[pgsql-es-ayuda] PREGUNTA SOPORTE

Buenos Dias!

 

mi pregunta es la siguiente ... vamos a adquirir un servidor con las siguientes características:

 

PROLIANT DL360G5 (1) Quad-Core Intel® Xeon® E5430 Processor (2.66 GHz, 80 Watts, 1333 FSB) Memoria Cache 12MB (2 x 6MB) Level 2 cache

Memoria Ram 2 GB (2 x 1GB) Standard PC2-5300 Fully Buffered DIMMs (DDR2-667)

Controladora de Discos HP Smart Array P400i/256MB Controller (RAID 0/1/1+0/5) 512MB BBWC or BBWC optional upgrades

PCI-Express Slots 1 full-length x8 PCI-Express slot 1 low-profile x8 PCI-Express slot

Ventildores 9 en total con redundancia standard

 MEMORIA 16 GB FBD PC2-5300 (NUEVA GENERACION) $ 1.041 $ 1.041

1  PROCESADOR Xeon Quad-Core E5430 (2.66 GHz, 80 Watts, 1333 FSB)

6 DISCO DURO 146GB 10k SAS 2.5 Hot Plug (NUEVA GENERACION) $ 393 $ 2.360

 

 

quisiera saber si PostgreSQL aprovecharía esta configuración al máximo 

Re: [HACKERS] Do we really need a 7.4.22 release now?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

>> Frankly, the whole pg_dump mess is what keeps many people on older versions,
>> somtimes including 7.4.

> Sure but that was fixed, four years ago. At some point you recognize
> laziness and ineptness over caution and responsibility.

I think you misunderstand my "mess". I'm referring to the fact that the only
way to upgrade between major versions is with pg_dump and reload, which
really, really sucks for large databases.

- From a business perspective, there has been no reason to go through the
pain and downtime of an upgrade, as long as the PG project is releasing
point revisions to the 7.4 branch. As I said, I'm all for getting people
off 7.4, but it needs to be done with a definite date, and December is
way too soon.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200809181205
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkjSfRYACgkQvJuQZxSWSsgcAgCeJi5t23JhHIOBHDRqXMYneJaW
pKoAoPflQaE6G6HR4H0OAsCC1BWiMt9g
=Tz0+
-----END PGP SIGNATURE-----

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [pgsql-www] Download links

On Thu, Sep 18, 2008 at 5:00 PM, Andrew Sullivan <ajs@commandprompt.com> wrote:
> On Wed, Sep 17, 2008 at 03:38:29PM -0700, Josh Berkus wrote:
>
>> (2) we move it to a section clearly labelled as "commercial distributors".
>
> We could change the name to "other", but other than that this seems to
> me to be a good idea. Anything hosted elsewhere can be marked this
> way.

That will have precisely the opposite effect to that which we want -
namely, it will direct users to the extremely limited downloads on our
own site, and away from both the one-click and distro-specific
releases which virtually all come from third party sites and are what
the majority of people want.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

Re: [HACKERS] New FSM patch

Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Here's a new patch, updated per your comments.

I did a read-through of the portions of this patch that change the rest
of the system (ie, not the guts of the new FSM itself). Mostly it looks
pretty nice, but I have a few gripes:

Does smgrimmedsync at the bottom of nbtsort.c need to cover FSM too?
Maybe not, since index's FSM should be empty, but in that case you
still should add a comment saying so.

Likewise for smgrimmedsync in tablecmds.c's copy_relation_data

Grepping for P_NEW suggests that you missed some places where
FreeSpaceMapExtendRel or IndexFreeSpaceMapExtend calls should be added.
In particular GiST/GIN. (I assume hash indexes still don't use FSM.
I wonder whether it'd be a good idea to get rid of hash bitmap pages
in favor of using FSM? TODO item, not material for this patch.)

The change in catalog/heap.c invalidates the comment immediately
above it.

In vacuum.c's vac_update_fsm, the outPages counter is now useless.

In vacuumlazy.c, the num_free_pages, max_free_pages, and tot_free_pages
members of LVRelStats are now useless, as is the comment above them.
You need to take out the reporting of tot_free_pages if you are not
going to track it.

I think it's a modularity violation for bufmgr.c to be calling FSM.
Furthermore, it's pretty useless to have RelationTruncate doing
the fixup only for heaps and not indexes. Please move that out
to the callers instead.

Does smgr.c still need to include storage/freespace.h at all?
Again, I think it would be a modularity violation to have it
calling FSM, now that FSM lives on top of storage.

RESOURCES_FSM needs to be removed from utils/guc_tables.h

The NOTE in the enum ForkNumber declaration was wrong before and
still is.

GetFreeSpaceOnPage() seems a bit misleadingly named; it's not obvious
from the name that it's not giving you the *true* free space on the page
but rather what FSM thinks it is. Maybe call it something like
GetRecordedFreeSpace(). Also, please do not use the declaration style
that omits parameter names; I think those are important for
documentation/readability.

Doc updates are missing, but you knew that.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [NOVICE] cpu utilization question

On Sep 18, 2008, at 10:59 AM, Wright, George wrote:

We did profile the sql. The stand alone statements generally execute in less than 30 ms. The clients (not browsers) send very short delimited text messages to the server. The server parses them and inserts a record for each message and only returns an HTTP 200, 400 to the client.

 

I guess my confusion is why such a short message would cause postmaster to use so much CPU. Several messages may arrive simultaneously and that many postmasters get kicked off.

 

We are currently installing the pgpool tool but I was wondering if there were any other things I could try.

 

if a single SQL takes 30ms to insert... then I suspect it's a other PG process that takes up the CPU, may be a vacuum process?

 

 

---

From: ries van Twisk [mailto:pg@rvt.dds.nl] 
Sent: Thursday, September 18, 2008 11:46 AM
To: Wright, George
Subject: Re: [NOVICE] cpu utilization question

 

 

On Sep 18, 2008, at 10:09 AM, Wright, George wrote:

We're running Suse 10.2, PG 8.1.5, PHP 5.2.

 

We're seeing high CPU percentages for multiple instances of postmaster: 15 – 30% for each instance. I realize a new instance is spawned for each connection that is opened and we have lots of clients sending very small text messages to our app for which we record a row per message.

 

We also have other periodic jobs that get kicked off but don't use near the cpu percentage that postmaster seems to.

 

Is there a way to minimize postmaster's cpu usage or is there some way to share that process between requests?

 

Thx.

 

You could setup connection pooling for these clients (web clients I assume),

but be-careful with PHP Persistent connections... they are buggy... I never used pgPool,

but that might be something you need.

 

When it comes to solving your high CPU processes you need to take a look why it's slow.

Use explain analyze as a start...

 

 

 

                                                regards, Ries van Twisk

 

 

-------------------------------------------------------------------------------------------------

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

 

regards, Ries van Twisk

-------------------------------------------------------------------------------------------------

Ries van Twisk

tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS WebORB PostgreSQL DB-Architect

email: ries@vantwisk.nl

web:   http://www.rvantwisk.nl/

skype: callto://r.vantwisk