Friday, July 4, 2008

Re: [PERFORM] Fusion-io ioDrive

On Tue, Jul 1, 2008 at 5:18 PM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> I recently got my hands on a device called ioDrive from a company
> called Fusion-io. The ioDrive is essentially 80GB of flash on a PCI
> card.

[...]

> Service Time Percentile, millis
> R/W TPS R-O TPS 50th 80th 90th 95th
> RAID 182 673 18 32 42 64
> Fusion 971 4792 8 9 10 11

Essentially the same benchmark, but on a quad Xeon 2GHz with 3GB main
memory, and the scale factor of 300. Really all we learn from this
exercise is the sheer futility of throwing CPU at PostgreSQL.

R/W TPS: 1168
R-O TPS: 6877

Quadrupling the CPU resources and tripling the RAM results in a 20% or
44% performance increase on read/write and read-only loads,
respectively. The system loafs along with 2-3 CPUs completely idle,
although oddly iowait is 0%. I think the system is constrained by
context switch, which is tens of thousands per second. This is a
problem with the ioDrive software, not with pg.

Someone asked for bonnie++ output:

Block output: 495MB/s, 81% CPU
Block input: 676MB/s, 93% CPU
Block rewrite: 262MB/s, 59% CPU

Pretty respectable. In the same ballpark as an HP MSA70 + P800 with
25 spindles.

-jwb

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

Re: [HACKERS] PATCH: CITEXT 2.0

Replying to myself, but I've made some local changes (see other
messages) and just wanted to follow up on some of my own comments.

On Jul 2, 2008, at 21:38, David E. Wheeler wrote:

>> 4) Operator = citext_eq is not correct. See comment http://doxygen.postgresql.org/varlena_8c.html#8621d064d14f259c594e4df3c1a64cac
>
> So should citextcmp() call strncmp() instead of varst_cmp()? The
> latter is what I saw in varlena.c.

I'm guessing that the answer is "no," since varstr_cmp() uses
strncmp() internally, as appropriate to the locale. Correct?

>> There must be difference between equality and collation for example
>> in Czech language 'láska' and 'laská' are different word it means
>> that 'láska' != 'laská'. But there is no difference in collation
>> order. See Unicode Universal Collation Algorithm for detail.
>
> I'll leave the collation stuff to the functions I call (*far* from
> my specialty), but I'll add a test for this and make sure it works
> as expected. Um, although, with what collation should it be tested?
> The tests I wrote assume en_US.UTF-8.

I added this test and is passes:

SELECT isnt( 'láska'::citext, 'laská'::citext, 'Diffrent accented
characters should not be equivalent' );

>> 5) There are several commented out lines in CREATE OPERATOR
>> statement mostly related to NEGATOR. Is there some reason for that?
>
> I copied it from the original citext.sql. Not sure what effect it has.

I restored these (and one of them was wrong anyway).

>> Also OPERATOR || has probably wrong negator.
>
> Right, good catch.

Stupid question: What would the negation of || actually be? There
isn't one is, there?

Thanks!

David
--
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] PATCH: CITEXT 2.0

On Jul 2, 2008, at 22:14, Tom Lane wrote:

> The "leak" is irrelevant for larger/smaller. The only place where
> it's
> actually useful to do PG_FREE_IF_COPY is in a btree or hash index
> support function. In other cases you can assume that you're being
> called in a memory context that's too short-lived for it to matter.

Stupid question: for the btree index support function, is that *only*
the function referenced in the OPERATOR CLASS, or does it also apply
to functions that implement the operators in that class? IOW, do I
need to worry about memory leaks in citext_eq, citext_ne, citext_gt,
etc., or only in citext_cmp()?

Thanks,

David

--
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] PATCH: CITEXT 2.0

On Jul 3, 2008, at 09:53, Alvaro Herrera wrote:

>> Thanks. What would citext_hash() look like? I don't see a
>> text_hash() to
>> borrow from anywhere in src/.
>
> See hash_any(). I assume the difficulty is making sure that
> hash("FOO") = hash("foo") ...

Great, big help, thank you. So does this look sensible?

Datum
citext_hash(PG_FUNCTION_ARGS)
{
char *txt;
char *str;
Datum result;

txt = cilower( PG_GETARG_TEXT_PP(0) );
str = VARDATA_ANY(txt);

result = hash_any((unsigned char *) str, VARSIZE_ANY_EXHDR(txt));

/* Avoid leaking memory for toasted inputs */
PG_FREE_IF_COPY(txt, 0);
pfree( str );

return result;
}

And how might I be able to test that it actually works?

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

Re: [pgsql-es-ayuda] DATESTYLE

Porke no manejas el formato con to_char o to_date?

Saludos,


2008/7/4, Noel Martínez Juárez <noelius79@hotmail.com>:
> Buenas noches, he intentado cambiar el formato de la fecha en postgresql, a
> día-mes-año, pero el PG-ADMIN no me muestra dicho cambio, la variable que
> modifico es DATESTYLE, gracias.NOEL
>
> _________________________________________________________________
> Juega y gana, tenemos 3 Xbox a la semana.
> http://club.prodigymsn.com/


--
Fabio Hernando Arias Vera
Cel. 314 411 7776
--
TIP 8: explain analyze es tu amigo

[pgsql-es-ayuda] DATESTYLE

Buenas noches, he intentado cambiar el formato de la fecha en postgresql, a día-mes-año, pero el PG-ADMIN no me muestra dicho cambio, la variable que modifico es DATESTYLE, gracias.

NOEL



Conoce el perfil completo de todos tus amigos de Windows Live Messenger justo aquí: Windows Live Spaces

Re: [PORTS] Fwd: 8.3.3 compile fails on Mac OS X 10.5.2

Tom Lane wrote:
> > When I blow away /sw/bin/awk, so that make uses /usr/bin/awk instead,
> > I get a make that executes perfectly and a make check with "All 114
> > tests passed."
>
> <spock>Fascinating.</spock>

OK, that wins the most creative tag award from me.

--
Bruce Momjian <bruce@momjian.us>

http://momjian.us

EnterpriseDB

http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

[PORTS] contrib - fuzzystrmatch installation issue

Hi everyone,

I am running Postgres 8.3.3 on a CentOS box and I had a few issues when trying to install the fuzzystrmatch library. The library seemed to compile and make install correctly, but when I ran the sql scripts to add the functions to a database, I came up with this issue:

# psql -d template1 -U postgres -f fuzzystrmatch.sql
SET
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
psql:fuzzystrmatch.sql:24: ERROR:  could not find function "difference" in file "/usr/lib/pgsql/fuzzystrmatch.so"
psql:fuzzystrmatch.sql:28: ERROR:  could not find function "dmetaphone" in file "/usr/lib/pgsql/fuzzystrmatch.so"
psql:fuzzystrmatch.sql:32: ERROR:  could not find function "dmetaphone_alt" in file "/usr/lib/pgsql/fuzzystrmatch.so"

Apparently, these three functions did not compile into the module. I'm not much of a C/C++ programmer, but according to the Makefile, both object files were included in the resulting fuzzystrmatch shared object, and the three functions in question where definitely present in fuzzystrmatch.c to begin with.

The following is a list of symbols inside the shared object:

# nm libfuzzystrmatch.so
00002ee4 A __bss_start
00000938 t call_gmon_start
00002ec4 D _codes
00002ee4 b completed.1
00002d7c d __CTOR_END__
00002d78 d __CTOR_LIST__
         U __ctype_b_loc@@GLIBC_2.3
         U __ctype_toupper_loc@@GLIBC_2.3
         U CurrentMemoryContext
         w __cxa_finalize@@GLIBC_2.1.3
00001a64 T difference
         U DirectFunctionCall1
00001ae8 t __do_global_ctors_aux
0000095c t __do_global_dtors_aux
00002ebc d __dso_handle
00002d84 d __DTOR_END__
00002d80 d __DTOR_LIST__
00002d8c A _DYNAMIC
00002ee4 A _edata
         U elog_finish
         U elog_start
00002ee8 A _end
         U errcode
         U errfinish
         U errmsg
         U errstart
00001b18 T _fini
000009b8 t frame_dummy
00001d74 r __FRAME_END__
00001bd4 r __func__.2
00001ca4 r __func__.3
00001bc4 r __func__.5
00002e78 A _GLOBAL_OFFSET_TABLE_
         w __gmon_start__
00000830 T _init
00002d88 d __JCR_END__
00002d88 d __JCR_LIST__
         w _Jv_RegisterClasses
00000f7e t .L1027
000011d7 t .L1034
00001340 t .L110
000012f5 t .L180
000013a8 t .L185
00000d8f t .L208
00000eac t .L253
00001132 t .L254
00001096 t .L266
0000102d t .L392
00000e27 t .L487
00000f90 t .L667
00000f1d t .L760
0000105e t .L774
00000f40 t .L785
0000117f t .L789
00000d55 t .L83
000012a4 t .L874
0000116a t .L930
000011fe t .L932
00000f5c t .L977
000013c7 t .L98
00001251 t .L982
00000a24 T levenshtein
00000bf4 T Lookahead
         U MemoryContextAlloc
000016ac T metaphone
00000c24 T _metaphone
00001cb4 r my_finfo.0
00001cb0 r my_finfo.1
00001bd0 r my_finfo.4
00001bc0 r my_finfo.6
00002ec0 d p.0
         U pg_detoast_datum
00001a4c T pg_finfo_difference
00000a0c T pg_finfo_levenshtein
00000bdc T pg_finfo_metaphone
000018f8 T pg_finfo_soundex
00001bac r Pg_magic_data.7
000009f4 T Pg_magic_func
00001a00 T soundex
00001910 t _soundex
00002ee0 d soundex_table
         U textin
         U textout

The compiler didn't return any errors during the build process, leaving me clueless as to why it's not working correctly. Any help would be greatly appreciated.

Thanks,
Kenaniah Cerny

[COMMITTERS] veil - veil: Initial release of changes for serialisation.

Log Message:
-----------
Initial release of changes for serialisation. All session variables
are now serialisable. Still need to do serialisation of the session
as a whole. Also comments are needed but regression tests look good.

Modified Files:
--------------
veil/demo:
funcs.sql (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/demo/funcs.sql.diff?r1=1.2&r2=1.3)
veil/docs:
Doxyfile (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/docs/Doxyfile.diff?r1=1.11&r2=1.12)
veil/regress:
regress.sh (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/regress/regress.sh.diff?r1=1.5&r2=1.6)
veil/src:
veil_bitmap.c (r1.4 -> r1.5)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_bitmap.c.diff?r1=1.4&r2=1.5)
veil_config.c (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_config.c.diff?r1=1.3&r2=1.4)
veil_datatypes.h (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_datatypes.h.diff?r1=1.5&r2=1.6)
veil_funcs.h (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_funcs.h.diff?r1=1.5&r2=1.6)
veil_interface.c (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_interface.c.diff?r1=1.7&r2=1.8)
veil_interface.sqs (r1.3 -> r1.4)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_interface.sqs.diff?r1=1.3&r2=1.4)
veil_shmem.c (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_shmem.c.diff?r1=1.7&r2=1.8)
veil_variables.c (r1.5 -> r1.6)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_variables.c.diff?r1=1.5&r2=1.6)
veil_version.h.in (r1.7 -> r1.8)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/veil/veil/src/veil_version.h.in.diff?r1=1.7&r2=1.8)

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

[BUGS] BUG #4281: some types of errors do not log statements

The following bug has been logged online:

Bug reference: 4281
Logged by: thomas
Email address: me@alternize.com
PostgreSQL version: 8.3.3
Operating system: Windows 2003
Description: some types of errors do not log statements
Details:

this isn't really a bug but rather a request for an improvement.

i've noticed that in some cases of errornous sql statements, the statement
itself is logged to the pg_log, in other cases it isn't:

logged:

2008-07-05 01:53:02 CEST 3528 486eade5.dc8 10.1.1.71(53082)ERROR: column
"xyz" does not exist at character 294
2008-07-05 01:53:02 CEST 3528 486eade5.dc8 10.1.1.71(53082)STATEMENT:
SELECT xyz FROM test


not logged:

2008-07-05 02:16:15 CEST 6644 486ebab4.19f4 127.0.0.1(1616)ERROR: invalid
byte sequence for encoding "UTF8": 0xc474
2008-07-05 02:16:15 CEST 6644 486ebab4.19f4 127.0.0.1(1616)HINT: This error
can also happen if the byte sequence does not match the encoding expected by
the server, which is controlled by "client_encoding".


it would be usefull to always see the sql statement that provoked the error.
especially in the case of wrong utf byte sequences it can get very difficult
to find the point of failure without more information.

thanks,
thomas

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

[pgadmin-hackers] First beta release of pgScript

Hi pgadmin hackers,

My Google Summer of Code project pgScript is going on pretty well. I
have just released a standalone beta version. As a reminder, my final
goal is to integrate pgScript into the Query Tool of pgAdmin and then
provide:
* Control-of-flow language
* Local variables
* Random data generators

The website with the documentation: http://pgscript.projects.postgresql.org
The page for download: http://pgfoundry.org/frs/?group_id=1000371

* pgScript-1.0-beta-1.exe : Windows binary file directly usable
* pgScript-1.0-beta-1.tar.gz : Source, can be compiled with g++
(tested in Slackware and MinGW)

I hope I will get your feedbacks,
Mickael

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

Re: [ADMIN] How many table scans in a delete...

On Fri, Jul 4, 2008 at 10:00 AM, Jessica Richard <rjessil@yahoo.com> wrote:
> I am just trying to understand how Postgres does its delete work.
>
> If I have a table testDad with a primary key on cola and no index on colb,
> and I have a kid table testKid with a foreign key to reference testDad but
> no index created on the foreign key column on table testKid.
>
> I have 10,000 rows in each table and I want to delete 5000 rows from the Dad
> table, of course , I have to kill all the kids in the Kid table first so
> that I won't get the constraint error.

Generally speaking, that's doing things wrong. It's generally easier
to use a cascading delete fk so that you don't have to delete the rows
from the kid table first.

> Now I am ready to run my delete command on the Dad table with the following
> command:
>
> delete from testDad where colb = 'abc';
>
> (supposed select count(*) from testDad where colb = 'abc' will give me 5000
> rows)
>
> Since I don't have any index on testDad.colb, I know it is going to do a
> table scan on the table testDad to find all the qualified rows for the
> delete.
>
> My question1: how many table scans will this single transaction do to find
> all 5000 qualified rows on the Dad table testDad? Does it scan the entire
> table once to get all qualified deletes? or it has to do the table scan 5000
> times on testDad?

One on table Dad.

> then, after all the 5000 qualified rows have been found on table testDad,
> the constraints between the Dad and Kid table will be checked against those
> 5000 qualified rows on table testDad.
>
> My question 2: does it take one qualified row at a time from the Dad table
> then do a table scan on the kid table for constraint check? In this case,
> it will have to do 5000 times of table scan on the kid table. very unlikely
> it will scan the kid table only once to do all constraint checking for 5000
> different primary values...

Maybe. Depends on how much memory it would take to run it with
various join methods. But the worst case scenario is a seq scan on
the child table for each row in Dad table. Which is why it's a good
idea to use indexes on FK fields.

--
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] Problema con caractere en un select

El día 4 de julio de 2008 17:21, Fernando Siguenza <fsigu@hotmail.com> escribió:
>
> Amigos yo nuevamente espero me puedan dar una mano ota ves muchas gracias a
> todos los que me han ayudado hasta el momento
> ahora tengo otro inconveniente, quiero realizar un select a la base de
> datos.
> tengo un campo de tipo cod varchar(3) y otro nom varchar(20) lo que quiero
> hacer es esto
> select * from tabla where cod like '%' or nom like '%' para que me retorne
> todos los valores.

quieres saber si cod o nom contiene el string "%" ???
--
TIP 7: no olvides aumentar la configuración del "free space map"

[pgsql-es-ayuda] Manejo de Imagenes

Un gusto Saludarlos
Quisiera molestarlos eh estado investigando la forma de poder insertar o
eliminar imagenes a una tabla desde el pgadmin y mandando a llamar las
imagenes a una maquina de W$, si alguien me pudiera ayudar con un
pequeño ejemplo para poder hacer mis pruebas.
Ademas eh tenido algunos inconvenientes con mi tabla de usuarios ya que
a veces mi aplicacion no llama bien a los usuarios para que se
autentiquen en la aplicacion y la solucion ah sido reindexar la tabla y
despues de ello no tengo inconvenientes, tengo ejecutando autovacuum y
creen ustedes que es recomendable poner en un Cron que reindexe todos
los dias mi tabla de usuarios.?

Utilizo
Postgresql 8.3
OS Leopard
De antemano Gracias.
Douglas Escobar

--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)

[pgsql-es-ayuda] Problema con caractere en un select


Amigos yo nuevamente espero me puedan dar una mano ota ves muchas gracias a todos los que me han ayudado hasta el momento
ahora tengo otro inconveniente, quiero realizar un select a la base de datos.
tengo un campo de tipo cod varchar(3) y otro nom varchar(20) lo que quiero hacer es esto
select * from tabla where cod like '%' or nom like '%' para que me retorne todos los valores.

Pero al realizar la consulta me sale esto

ERROR: 42883: operator does not exist: @ character varying

estos con mis parametros

comando.Parameters.Add(new NpgsqlParameter("@AgeCod", NpgsqlDbType.Char, 3)).Value = cod + '%';
comando.Parameters.Add(new NpgsqlParameter("@AgeNom", NpgsqlDbType.Char, 20)).Value = nom + '%';

cual puede ser el error, he intentado concatenar con doble comillas y nada me da el mismo erro

Espero que me puedan ayudar. estoy usando Npgsql con c#

Saludos

Blog your life in 3D with Windows Live Writer. Get Windows Live-Free

RE: [pgsql-es-ayuda] Error en Insert


Gracias raul realmente ese rea el problema yo estaba considerando que era un valor de 12 enteros y 5 decimales.
Ahora que he corregido eso tengo otro incinveniente, quiero realizar un select a la base de datos.
tengo un campo de tipo cod varchar(3) y otro nom varchar(20) lo que quiero hacer es esto
select * from tabla where cod like '%' or nom like '%' para que me retorne todos los valores.

Pero al realizar la consulta me sale esto

ERROR: 42883: operator does not exist: @ character varying

esots con mis parametros
comando.Parameters.Add(new NpgsqlParameter("@AgeCod", NpgsqlDbType.Char, 3)).Value = cod + '%';
comando.Parameters.Add(new NpgsqlParameter("@AgeNom", NpgsqlDbType.Char, 20)).Value = nom + '%';

cual puede ser el error, he intentado concatenar con doble comillas y nada me da el mismo erro

Espero que me puedan ayudar.

Saludos

> From: ra_duque@yahoo.com.mx
> To: baron.rojo.cuerdas.de.acero@gmail.com; fsigu@hotmail.com
> CC: pgsql-es-ayuda@postgresql.org
> Subject: Re: [pgsql-es-ayuda] Error en Insert
> Date: Fri, 4 Jul 2008 12:03:40 +0200
>
>
>
> --------------------------------------------------
> From: 'Marcos Saldivar' <baron.rojo.cuerdas.de.acero@gmail.com>
> Sent: Friday, July 04, 2008 5:48 PM
> To: 'Fernando Siguenza' <fsigu@hotmail.com>
> Cc: <pgsql-es-ayuda@postgresql.org>
> Subject: Re: [pgsql-es-ayuda] Error en Insert
>
> > 2008/7/4 Fernando Siguenza <fsigu@hotmail.com>:
> >>
> >>
> >>> Date: Fri, 4 Jul 2008 10:03:22 -0400
> >>> From: baron.rojo.cuerdas.de.acero@gmail.com
> >>> To: fsigu@hotmail.com
> >>> Subject: Re: [pgsql-es-ayuda] Error en Insert
> >>> CC: pgsql-es-ayuda@postgresql.org
> >>>
> >>> 2008/7/4 Fernando Siguenza <fsigu@hotmail.com>:
> >>> > Amigos como estan, de nuevo recurro a su ayuda, estoy iniciandome en
> >>> > t¡esto
> >>> > de postgre y punto net, y tengo un problema, en la base de dartos
> >>> > tengo
> >>> > uan
> >>> > tabla y un campodefinido como numeric 12,5, pero al intentar realizar
> >>> > un
> >>> > insert desde el c# tengo me muestre este mensaje.
> >>> > ERROR: 22003: numeric field overflow.
> >>> >
> >>> > El campo que intendo insertar esta declarado igual como numeric, he
> >>> > probado
> >>> > con doble y nada, este es el parametro y comando que uso
> >>> >
> >>> > comando.Parameters.Add(new
> >>> > NpgsqlParameter('@saldo',NpgsqlDbType.Numeric,12)).Value=cos
> >>> >
> >>>
> >>> no se nada de punto net, pero el valor que quieres ingresar es mayor a
> >>> 9.999.999,99999 ???
> >>> --
> >>> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> >>> http://archives.postgresql.org/pgsql-es-ayuda
> >>
> >> No realmente solo para pruebas quise poner 12.5, y con este valor no me
> >> deja... Help Me Please
> >
> > Yo entendí que tenias un 'campo numeric(12,5)' de todas formas el error es
> > de que intentas almacenar un valor que no acepta la definición de la
> > columna,
> > te sugiero que imprimas el valor a insertar justo antes de hacer el
> > insert ya que
> > puede estar intentado ingresar un 12.49999999999 o algo asi.
> >
>
> Recuerda que un numeric (12, 5) quiere decir que son 7 números enteros y 5
> decimales.
>
> Atentamente,
>
> RAUL DUQUE
> BOGOTÁ, COLOMBIA
>
> > Al final la columna que te da el error en el insert como esta definida ???
> > --
> > TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
> > http://archives.postgresql.org/pgsql-es-ayuda
> >
> > __________ Information from ESET Smart Security, version of virus
> > signature database 3243 (20080704) __________
> >
> > The message was checked by ESET Smart Security.
> >
> > http://www.eset.com
> >
> >
> --
> TIP 5: ¿Has leído nuestro extenso FAQ?
> http://www.postgresql.org/docs/faqs.FAQ.html


Get your fix of news, sports, entertainment and more on MSN Mobile Get your fix now!

Re: [GENERAL] [Postgresql 8.2.3] autovacuum starting up even after disabling ?

Hey,

>> There is only one autovacuum process when it starts up. Below is the
>> correct output from one of the logs
>
> Good.
>
> Do you have entries in the pg_autovacuum table in this database?

No. Its empty.

TIA
Dushyanth

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

Re: [PATCHES] Relation forks & FSM rewrite patches

Alvaro Herrera wrote:
> I wonder if we could instead make vacuum write a new FSM tree from
> scratch, rather than updating it piecemeal.

I'd like to move away from that, as we'll hopefully get some sort of
partial vacuum capability soon.

We might want to have some sort of bulk update operation, though, so
that you could refresh FSM information for say 100 pages, or one FSM
page, at a time. That would reduce the WAL traffic of a VACUUM
significantly, though I'm not sure how significant that is to begin with.

--
Heikki Linnakangas
EnterpriseDB

http://www.enterprisedb.com

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

Re: [HACKERS] gsoc, text search selectivity and dllist enhancments

Tom Lane wrote:
> "Heikki Linnakangas" <heikki@enterprisedb.com> writes:
>> Tom Lane wrote:
>>> The data structure I'd suggest is a simple array of pointers
>>> to the underlying hash table entries. Since you have a predetermined
>>> maximum number of lexemes to track, you can just palloc the array once
>>> --- you don't need the expansibility properties of a list.
>
>> The number of lexemes isn't predetermined. It's 2 * (longest tsvector
>> seen so far), and we don't know beforehand how long the longest tsvector is.
>
> Hmm, I had just assumed without looking too closely that it was stats
> target times a fudge factor. What is the rationale for doing it as
> above? I don't think I like the idea of the limit varying over the
> course of the scan --- that means that lexemes in different places
> in the input will have significantly different probabilities of
> surviving to the final result.

Well, clearly if the list is smaller than the longest tsvector,
inserting all elements of that long tsvector will flush out all other
entries. Or if we throw away the newly inserted entries, some elements
will never have a chance to climb up the list. I'm not sure where the
"times two" figure comes from, maybe it's just a fudge factor, but the
bottom line is that the minimum size needed depends on the size of the
longest tsvector.

(Jan is offline until Saturday...)

--
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: [COMMITTERS] pgsql: Fix a couple of bugs in win32 shmem name generation: * Don't cut

Magnus Hagander wrote:
> Tom Lane wrote:

> > According to what you just told me, the original coding is storing the
> > name in a "local namespace", which presumably means it won't conflict
> > anyway. Ergo, the existing coding is simply broken and there's nothing
> > we can do about it.
>
> Local namespace = Session local, not process local. So it would properly
> protect against two processes started in the same session. One session
> is, for example, an interactive login. But not if they were started by
> different users, since they'd be in different sessions.

But those different users would not have access to the same set of
files, so it wouldn't work anyway, right?

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

Re: [GENERAL] [Postgresql 8.2.3] autovacuum starting up even after disabling ?

dushy escribió:

> My bad - I messed up the above. I grepped for autovacuum in my process
> logs and included all matches.

Ah, ok -- that makes more sense.

> There is only one autovacuum process when it starts up. Below is the
> correct output from one of the logs

Good.

Do you have entries in the pg_autovacuum table in this database?

--
Alvaro Herrera

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

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

Re: [PERFORM] [QUESTION]Concurrent Access

tlevisilva@gmail.com ("Leví Teodoro da Silva") writes:
> Hi guys, How are you ?
> I am from Brazil and i work for a little company and it company is working is medium-big project and we want to use PostGree like the DataBase
> system, but i got some questions.
> I want to know if the PostGree has limitations about the concurrent access, because a lot of people will access this database at the same time.
> I want to know about the limitations, like how much memory do i have to use !? How big could be my database and how simultaneously access this
> database support ?

PostGree is a system I am not familiar with; this list is for
discussion of PostgreSQL, sometimes aliased as "Postgres," so I will
assume you are referring instead to PostgreSQL.

PostgreSQL does have limitations; each connection spawns a process,
and makes use of its own "work_mem", which has the result that the
more connections you configure a particular backend to support, the
more memory that will consume, and eventually your system will
presumably run out of memory.

The size of the database doesn't have as much to do with how many
users you can support as does the configuration that you set up.
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://cbbrowne.com/info/lsf.html
Rules of the Evil Overlord #145. "My dungeon cell decor will not
feature exposed pipes. While they add to the gloomy atmosphere, they
are good conductors of vibrations and a lot of prisoners know Morse
code." <http://www.eviloverlord.com/>

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