Sunday, June 29, 2008

[GENERAL] tsearch strategy for incremental search

I am trying to implement an incremental search engine. The service
should start searching when the user has typed at least 3 characters.
I am thinking of using the following strategy:

a) Create a function string_to_three_char_tsvector(str text) that
would generate the tsvector composed of the three-letter lexemes that
begin all the admissible words within the parameter str.
b) Using this function, create an indexed tsvector column: three_char_index.
c) Given the query string query_string (assume query_string containing
at least 3 characters):
SELECT *
FROM mytable, plainto_tsquery((string_to_three_char_tsvector(query_string))::text)
AS query
WHERE three_char_index @@ query
AND text_field LIKE '%' || str || '%';

Once I've narrowed the field of possibilities down to the correct
3-letter lexemes, there are fewer than 100 lines to search through
with LIKE. I could even repeat the exercise with 4-letter lexemes if
these numbers were to grow or if I needed the extra boost in
performance.

So, two questions to postgres/tsearch experts:

1) Does that seem like a decent overall strategy?

2) About the function string_to_three_char_tsvector(text), I cannot
think of an elegant way of writing this. Is it possible to do better
than the following:

str => cast to tsvector => cast to text => for each lexeme-string,
take first-three-char substring => concat back together => cast to
tsvector

Is there a nice way of performing the middle operation? Like
splitting the string to an array...

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

Re: [pgsql-es-ayuda] indices

Fijate que en ambas consultas no estas filtrando por ningun campo, por lo cual, la consulta barre toda la tabla (full access).
En este caso en particular la creacion de indices no te ayuda en nada.
Distinta seria la historia si en al consulta pusieras algo del estilo "where ddd > algo " o algun caso por el estilo....

saludos Pablo


El día 29 de junio de 2008 21:37, Sandrigo L.Jara <sandrigo.lezcano@gmail.com> escribió:
migre 22 millones de registros en una tabla en PostgreSQL 8.2
ddds, numeros..etc   ..ddds del tipo: character varying(3)
que quando ejecuto:
 
-- sin indices
-- Executing query:
SELECT ddd, count(ddd) AS cantidad FROM tabla GROUP BY 1 ORDER BY 1
Total query runtime: 432421 ms.
65 rows retrieved.
 
-- Executing query:
CREATE INDEX tabla_idx_ddd ON tabla (ddd)
Query returned successfully with no result in 496755 ms.
 
nuevamente ahora ya con indice...
 
-- Executing query:
SELECT ddd, count(ddd) AS cantidad FROM tabla GROUP BY 1 ORDER BY 1
Total query runtime: 404579 ms.
65 rows retrieved.
 
deberia ser mucho!!!!   mas rapido.. no??? 
agradezco todas las sugerencias
 
Abrazos a todos



--
Pablo Marrero
Tel: 099 927 566

[pgsql-es-ayuda] indices

migre 22 millones de registros en una tabla en PostgreSQL 8.2
ddds, numeros..etc   ..ddds del tipo: character varying(3)
que quando ejecuto:
 
-- sin indices
-- Executing query:
SELECT ddd, count(ddd) AS cantidad FROM tabla GROUP BY 1 ORDER BY 1
Total query runtime: 432421 ms.
65 rows retrieved.
 
-- Executing query:
CREATE INDEX tabla_idx_ddd ON tabla (ddd)
Query returned successfully with no result in 496755 ms.
 
nuevamente ahora ya con indice...
 
-- Executing query:
SELECT ddd, count(ddd) AS cantidad FROM tabla GROUP BY 1 ORDER BY 1
Total query runtime: 404579 ms.
65 rows retrieved.
 
deberia ser mucho!!!!   mas rapido.. no??? 
agradezco todas las sugerencias
 
Abrazos a todos

Re: [pgsql-es-ayuda] [OT] Cubanos en la lista

Saludos, no soy un experto, pero si te puedo asegurar que por esta vía he
logrado aclararme muchas dudas y siempre se aprende muchísimo de los
criterios de todos los que de una forma u otra participamos en el foro,
dando criterios y apoyando a los que como nosotros un día comenzaron.

Muchas gracias y claro que te tendré presente, demás está decirte que puedes
contar com mi ayuda.


----- Original Message -----
From: "Gabriel Hermes Colina Zambra" <hermeszambra@yahoo.com>
To: "Reynier Perez Mira" <rperezm@uci.cu>; <pgsql-es-ayuda@postgresql.org>;
"Edwin Quijada" <listas_quijada@hotmail.com>; "Juan Carlos Badillo Goy"
<badillo@cav.desoft.cu>
Sent: Sunday, June 29, 2008 7:53 PM
Subject: Re: [pgsql-es-ayuda] [OT] Cubanos en la lista

Esimado Juan Carlos, en PostgreSQL soy de "medio pelo" y ultimamente
confieso que he tenido un deficit de en la ayuda, pero siempre estoy
dispuesto a colaborar, en PHP me confieso ignorante, salvo por dos o tres
cositas chicas que implemente.

Como vengo de Visual Basic, gambas es el proyecto que adopte y me gusta
mucho, sobre todo por que esta bien orientado a objetos.

Si en algo te puede servir aca estoy para darte una mano. mi gtalk
ghcolina@gmail.com

Atte.
Gabriel Colina

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/
--
TIP 7: no olvides aumentar la configuración del "free space map"

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

Re: [pgsql-es-ayuda] [OT] Cubanos en la lista

Esimado Juan Carlos, en PostgreSQL soy de "medio pelo" y ultimamente confieso que he tenido un deficit de en la ayuda, pero siempre estoy dispuesto a colaborar, en PHP me confieso ignorante, salvo por dos o tres cositas chicas que implemente.

Como vengo de Visual Basic, gambas es el proyecto que adopte y me gusta mucho, sobre todo por que esta bien orientado a objetos.

Si en algo te puede servir aca estoy para darte una mano. mi gtalk ghcolina@gmail.com

Atte.
Gabriel Colina

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [pgsql-es-ayuda] [OT] Cubanos en la lista

Saludos, Reynier

Trabajo en Desoft Ciego de Avila y soy el jefe del proyecto de Gestión
Documental con Software libre, debo comenzar a trabajar con la facultad 10
que radica allí en la UCI, ayudandolos en la preparación en PostgreSQL para
que nos apoyen en el desarrollo de AvilaDOC un sistema en PHP y PostgreSQL.
El punto es que puedes contar con mi ayuda cuando me incorpore all'i en la
UCI en los proximos días.

Esperemos que se sigan sumando seguidores de PostgreSQL.


----- Original Message -----
From: "Reynier Perez Mira" <rperezm@uci.cu>
To: <hermeszambra@yahoo.com>; <pgsql-es-ayuda@postgresql.org>; "Edwin
Quijada" <listas_quijada@hotmail.com>
Sent: Sunday, June 29, 2008 7:20 PM
Subject: RE: [pgsql-es-ayuda] [OT] Cubanos en la lista


Hola Gabriel y Edwin:
No se de que va este tema pero bueno vamos a aclarar algunas cosas que dice
Gabriel.

Trabajo en la UCI (Universidad de Ciencias Informáticas) en Cuba y no me
encargo de los Proyectos Productivos directamente sino de casi toda la parte
tecnológica en la cual entra PostgreSQL como SGBD. Antes úsabamos MySQL y
algunas personas de forma aislada PostgreSQL pero como los EE.UU son los
EE.UU pues ahora Sun compró MySQL nosotros no podemos descargar nada desde
los servidores de Sun porque esos si que aplican la política de verdad. Por
tanto se ha decidido ir migrando todos nuestros sistemas de MySQL y algunos
que restan hoy en SQL Server a PostgreSQL.

Al igual como dice Gabriel en la medida de que vayamos aprendiendo
PostgreSQL podemos ayudar a aquellos que recién comienzan porque soy el
ejemplo vivo, gracias a la lista de PostgreSQL en español y a todos los que
aquí ayudan he podido adquirir un nivel básico de PostgreSQL pues la
asignatura SGBD la di en el 2do año de mis estudios.

Salu2 y espero por la respuesta de Edwin

Nota: Anteriormente no vi el mensaje sino hubiese respondido de inmediato

Ing. Reynier Pérez Mira
Grupo de Soporte al Desarrollo - Dirección Técnica IP

> Contactate con el amigo Reynier reynierpm@gmail.com es su gtalk, de la UCI
> (Universidad Cubana de Informatica), seguro le interese ya que es uno de
> los que se encarga de los proyectos productivos de la universidad, que por
> cierto adoptaron postgresql. Creo que en poco tiempo van a aportanos
> muchisimo, puesto que para ellos el software libre es una tarea de
> militancia.
>
> Un abrazo desde Uruguay
> Gabriel Colina
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.espanol.yahoo.com/
> --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
--
TIP 4: No hagas 'kill -9' a postmaster

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

Re: [GENERAL] libpq block allocated before my malloc handler inits?

rob wrote:
> I am trying to build a small program with libpq as the interface to a
> Postgre database. I am using the most current version. My program
> uses malloc and free hooks to manage memory without having to request
> memory from the system all the time. I expected that the init
> function (__malloc_initialize_hook) would run before anything else,
> but after opening a number of connections to the database with
> PQconnectdb, my program blows up because of a free which refers to a
> block of memory that wasn't allocated using my malloc function. My
> program runs without a hitch if I comment out the PQconnectdb function
> calls.
I've experienced an openSSL, libpq + other library using SSL bug
recently. Do you get the same crash is you explicitly disable SSL in
the connection string? sslmode=disable.

Thanks

Russell

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

Re: [pgsql-es-ayuda] Postgres y jdbc

Edgar Enriquez escribió:
> La pregrunta es si es posible de enviar md5 en una cadena de conección
> con postgresql-8.2-508.jdbc4?

No entiendo la pregunta. Si el servidor especifica el método md5 en
pg_hba.conf, entonces el envío se hará en md5, independiente de cómo la
pongas en el código fuente. (A diferencia del método password en
pg_hba.conf, que hace que la password se envíe en texto sin cifrar)

Dice la documentación:
http://www.postgresql.org/docs/8.3/static/auth-pg-hba-conf.html
md5

Require the client to supply an MD5-encrypted password for
authentication. See Section 21.2.2 for details.

password

Require the client to supply an unencrypted password for
authentication. Since the password is sent in clear text over the
network, this should not be used on untrusted networks. It also does
not usually work with threaded client applications. See Section
21.2.2 for details.


La sección 21.2.2 es
http://www.postgresql.org/docs/8.3/static/auth-methods.html#AUTH-PASSWORD
que dice lo siguiente:

The password-based authentication methods are md5, crypt, and
password. These methods operate similarly except for the way
that the password is sent across the connection: respectively,
MD5-hashed, crypt-encrypted, and clear-text. A limitation is
that the crypt method does not work with passwords that have
been encrypted in pg_authid.

If you are at all concerned about password "sniffing" attacks
then md5 is preferred, with crypt to be used only if you must
support pre-7.2 clients. Plain password should be avoided
especially for connections over the open Internet (...)

--
Alvaro Herrera

http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
TIP 8: explain analyze es tu amigo

RE: [pgsql-es-ayuda] [OT] Cubanos en la lista

Hola Gabriel y Edwin:
No se de que va este tema pero bueno vamos a aclarar algunas cosas que dice Gabriel.

Trabajo en la UCI (Universidad de Ciencias Informáticas) en Cuba y no me encargo de los Proyectos Productivos directamente sino de casi toda la parte tecnológica en la cual entra PostgreSQL como SGBD. Antes úsabamos MySQL y algunas personas de forma aislada PostgreSQL pero como los EE.UU son los EE.UU pues ahora Sun compró MySQL nosotros no podemos descargar nada desde los servidores de Sun porque esos si que aplican la política de verdad. Por tanto se ha decidido ir migrando todos nuestros sistemas de MySQL y algunos que restan hoy en SQL Server a PostgreSQL.

Al igual como dice Gabriel en la medida de que vayamos aprendiendo PostgreSQL podemos ayudar a aquellos que recién comienzan porque soy el ejemplo vivo, gracias a la lista de PostgreSQL en español y a todos los que aquí ayudan he podido adquirir un nivel básico de PostgreSQL pues la asignatura SGBD la di en el 2do año de mis estudios.

Salu2 y espero por la respuesta de Edwin

Nota: Anteriormente no vi el mensaje sino hubiese respondido de inmediato

Ing. Reynier Pérez Mira
Grupo de Soporte al Desarrollo - Dirección Técnica IP

> Contactate con el amigo Reynier reynierpm@gmail.com es su gtalk, de la UCI
> (Universidad Cubana de Informatica), seguro le interese ya que es uno de
> los que se encarga de los proyectos productivos de la universidad, que por
> cierto adoptaron postgresql. Creo que en poco tiempo van a aportanos
> muchisimo, puesto que para ellos el software libre es una tarea de
> militancia.
>
> Un abrazo desde Uruguay
> Gabriel Colina
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
> Regístrate ya - http://correo.espanol.yahoo.com/
> --
> TIP 1: para suscribirte y desuscribirte, visita
> http://archives.postgresql.org/pgsql-es-ayuda
--
TIP 4: No hagas 'kill -9' a postmaster

RE: [pgsql-es-ayuda] Return Query

> Date: Sun, 29 Jun 2008 00:29:57 -0500
> From: jcasanov@systemguards.com.ec
> To: listas_quijada@hotmail.com
> Subject: Re: [pgsql-es-ayuda] Return Query
> CC: pgsql-es-ayuda@postgresql.org
>
> On Sat, Jun 28, 2008 at 12:26 PM, Edwin Quijada
> wrote:
>>>>
>>>> Consigo el sigte error:
>>>> ERROR: a column definition list is required for functions returning "record"
>>>>
>>>
>>> create or replace function f1(out id_record integer, out alias text)
>>> returns setof record as
>>> $$
>>> begin
>>> return query select id_record,alias from uno_email_alias;
>>> end;
>>> $$ language plpgsql;
>>>
>> Jaime, como la invoco?
>
> select * from f1();

Consigo este error cuando lo hago asi

ERROR: structure of query does not match function result type
CONTEXT: PL/pgSQL function "f1" line 2 at RETURN QUERY

*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-849-8087

* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*

>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Guayaquil - Ecuador
> Cel. (593) 87171157
> --
> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo

_________________________________________________________________
Send funny voice messages packed with tidbits from MSN. Everyone wants to be ready.
http://www.noonewantstolookdumb.com?OCID=T001MSN54N1613A--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [GENERAL] libpq block allocated before my malloc handler inits?

rob wrote:

> Is there something that runs before my malloc init function in libpq?
> If there is, is there a way to make it happen afterwards? Is there a
> library interface which doesn't have hidden init functions?

I don't see anything in our code that would initialize stealthily.
Maybe it's something we're being linked against -- pthread perhaps?
OpenSSL? Maybe you'd have more luck if you noted what is libpq doing
when this invalid free is called. Perhaps call abort() and get a stack
trace from the resulting dump.

--
Alvaro Herrera

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

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

Re: [pgsql-es-ayuda] [OT] Cubanos en la lista

--- El sáb 28-jun-08, Edwin Quijada <listas_quijada@hotmail.com> escribió:

> De: Edwin Quijada <listas_quijada@hotmail.com>
> Asunto: [pgsql-es-ayuda] [OT] Cubanos en la lista
> A: pgsql-es-ayuda@postgresql.org
> Fecha: sábado, 28 junio, 2008, 4:08 pm
> Hay algun cubano por aca?
> Les tengo un regalo, contactenme antes del lunes. Pero que
> vivan en Cuba.
>
Edwin.

Contactate con el amigo Reynier reynierpm@gmail.com es su gtalk, de la UCI (Universidad Cubana de Informatica), seguro le interese ya que es uno de los que se encarga de los proyectos productivos de la universidad, que por cierto adoptaron postgresql. Creo que en poco tiempo van a aportanos muchisimo, puesto que para ellos el software libre es una tarea de militancia.

Un abrazo desde Uruguay
Gabriel Colina


__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [PERFORM] sequence scan problem

Oh, and the version is 8.3.3.

Jeremy Harris wrote:
> John Beaver wrote:
>> I'm having a strange problem with a query. The query is fairly
>> simple, with a few constants and two joins. All relevant columns
>> should be indexed, and I'm pretty sure there aren't any type
>> conversion issues. But the query plan includes a fairly heavy seq
>> scan. The only possible complication is that the tables involved are
>> fairly large - hundreds of millions of rows each.
>>
>> Can anyone explain this? There should only ever be a maximum of about
>> 50 rows returned when the query is executed.
>
> You didn't say when you last vacuumed?
> If there should only be 50 rows returned then the estimates from the
> planner are way out.
>
> If that doesn't help, we'll need version info, and (if you can afford
> the time) an "explain analyze"
>
> Cheers,
> Jeremy
>

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

Re: [BUGS] BUG #4274: uuid returns duplicate values

Hi.

I'm sorry delaying release bugfix was not included in pg8.3.3.
Please try this.

http://winpg.jp/~saito/pg_work/OSSP_win32/

Regards,
Hiroshi Saito

>
>The following bug has been logged online:
>
>Bug reference: 4274
>Logged by: eric melbardis
>Email address: eric.melbardis@netkitsolutions.com
>PostgreSQL version: 8.3.3
>Operating system: windows xp sp3
>Description: uuid returns duplicate values
>Details:
>
>the uuid functions do not return unique values if used sequntially, or i
>believe without too much tme in between invocations.
>
>the following test functions returns the same value!
>
>------------ test function ---------------
>create or replace function test_uuid()
>returns varchar as
>$body$
>begin
> raise notice 'uuid = %', uuid_generate_v4();
> raise notice 'uuid = %', uuid_generate_v4();
> raise notice 'uuid = %', uuid_generate_v4();
> raise notice 'uuid = %', uuid_generate_v4();
>end;
>$body$
>language 'plpgsql' ;
>
>--
>Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-bugs

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

Re: [PERFORM] sequence scan problem

Jeremy Harris wrote:
> John Beaver wrote:
>> I'm having a strange problem with a query. The query is fairly
>> simple, with a few constants and two joins. All relevant columns
>> should be indexed, and I'm pretty sure there aren't any type
>> conversion issues. But the query plan includes a fairly heavy seq
>> scan. The only possible complication is that the tables involved are
>> fairly large - hundreds of millions of rows each.
>>
>> Can anyone explain this? There should only ever be a maximum of about
>> 50 rows returned when the query is executed.
>
> You didn't say when you last vacuumed?
I ran 'vacuum analyze' on both tables directly after I finished building
them, and I haven't updated their contents since.
> If there should only be 50 rows returned then the estimates from the
> planner are way out.
>
> If that doesn't help, we'll need version info, and (if you can afford
> the time) an "explain analyze"
Sure, I'm running it now. I'll send the results when it's done, but yes,
it could take a while.
>
> Cheers,
> Jeremy
>

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

Re: [PERFORM] sequence scan problem

John Beaver wrote:
> I'm having a strange problem with a query. The query is fairly simple,
> with a few constants and two joins. All relevant columns should be
> indexed, and I'm pretty sure there aren't any type conversion issues.
> But the query plan includes a fairly heavy seq scan. The only possible
> complication is that the tables involved are fairly large - hundreds of
> millions of rows each.
>
> Can anyone explain this? There should only ever be a maximum of about 50
> rows returned when the query is executed.

You didn't say when you last vacuumed?
If there should only be 50 rows returned then the estimates from the
planner are way out.

If that doesn't help, we'll need version info, and (if you can afford
the time) an "explain analyze"

Cheers,
Jeremy

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

[PERFORM] sequence scan problem

I'm having a strange problem with a query. The query is fairly simple,
with a few constants and two joins. All relevant columns should be
indexed, and I'm pretty sure there aren't any type conversion issues.
But the query plan includes a fairly heavy seq scan. The only possible
complication is that the tables involved are fairly large - hundreds of
millions of rows each.

Can anyone explain this? There should only ever be a maximum of about 50
rows returned when the query is executed.

Query:

select fls.function_verified, fls.score, fls.go_category_group_ref,
fs1.gene_ref, fs1.function_verified_exactly, fs2.gene_ref,
fs2.function_verified_exactly from functional_linkage_scores fls,
gene_prediction_view fs1, gene_prediction_view fs2 where fls.gene_ref1 =
fs1.gene_ref and fls.gene_ref2 = fs2.gene_ref and fs1.go_term_ref = 2
and fs2.go_term_ref = 2

Explain on query:
Merge Join (cost=1331863800.16..6629339921.15 rows=352770803726 width=22)
Merge Cond: (fs2.gene_ref = fls.gene_ref2)
-> Index Scan using gene_prediction_view_gene_ref on
gene_prediction_view fs2 (cost=0.00..6235287.98 rows=197899 width=5)
Index Cond: (go_term_ref = 2)
-> Materialize (cost=1331794730.41..1416453931.72 rows=6772736105
width=21)
-> Sort (cost=1331794730.41..1348726570.67 rows=6772736105
width=21)
Sort Key: fls.gene_ref2
-> Merge Join (cost=38762951.04..146537410.33
rows=6772736105 width=21)
Merge Cond: (fs1.gene_ref = fls.gene_ref1)
-> Index Scan using gene_prediction_view_gene_ref
on gene_prediction_view fs1 (cost=0.00..6235287.98 rows=197899 width=5)
Index Cond: (go_term_ref = 2)
-> Materialize (cost=38713921.60..41618494.20
rows=232365808 width=20)
-> Sort (cost=38713921.60..39294836.12
rows=232365808 width=20)
Sort Key: fls.gene_ref1
-> Seq Scan on
functional_linkage_scores fls (cost=0.00..3928457.08 rows=232365808
width=20)


\d on functional_linkage_scores (232241678 rows):
Table "public.functional_linkage_scores"
Column | Type |
Modifiers
-----------------------+---------------+------------------------------------------------------------------------
id | integer | not null default
nextval('functional_linkage_scores_id_seq'::regclass)
gene_ref1 | integer | not null
gene_ref2 | integer | not null
function_verified | boolean | not null
score | numeric(12,4) | not null
go_category_group_ref | integer | not null
go_term_ref | integer |
Indexes:
"functional_linkage_scores_pkey" PRIMARY KEY, btree (id)
"functional_linkage_scores_gene_ref1_key" UNIQUE, btree (gene_ref1,
gene_ref2, go_category_group_ref, go_term_ref)
"ix_functional_linkage_scores_gene_ref2" btree (gene_ref2)
Foreign-key constraints:
"functional_linkage_scores_gene_ref1_fkey" FOREIGN KEY (gene_ref1)
REFERENCES genes(id)
"functional_linkage_scores_gene_ref2_fkey" FOREIGN KEY (gene_ref2)
REFERENCES genes(id)
"functional_linkage_scores_go_category_group_ref_fkey" FOREIGN KEY
(go_category_group_ref) REFERENCES go_category_groups(id)

\d on gene_prediction_view (568654245 rows):
Table
"public.gene_prediction_view"
Column | Type
| Modifiers
----------------------------------+------------------------+-------------------------------------------------------------------
id | integer | not null
default nextval('gene_prediction_view_id_seq'::regclass)
gene_ref | integer | not null
go_term_ref | integer | not null
go_description | character varying(200) | not null
go_category | character varying(50) | not null
function_verified_exactly | boolean | not null
function_verified_with_parent_go | boolean | not null
score | numeric(12,4) | not null
prediction_method_ref | integer |
functional_score_ref | integer |
Indexes:
"gene_prediction_view_pkey" PRIMARY KEY, btree (id)
"gene_prediction_view_functional_score_ref_key" UNIQUE, btree
(functional_score_ref)
"gene_prediction_view_gene_ref" UNIQUE, btree (gene_ref,
go_term_ref, prediction_method_ref)
Foreign-key constraints:
"gene_prediction_view_functional_score_ref_fkey" FOREIGN KEY
(functional_score_ref) REFERENCES functional_scores(id)
"gene_prediction_view_gene_ref_fkey" FOREIGN KEY (gene_ref)
REFERENCES genes(id)
"gene_prediction_view_go_term_ref_fkey" FOREIGN KEY (go_term_ref)
REFERENCES go_terms(term)

...and just in case someone can give advice on more aggressive settings
that might help out the planner for this particular comptuer...
This computer: Mac Pro / 4 gigs ram / software Raid 0 across two hard
drives.
Production computer: Xeon 3ghz / 32 gigs ram / Debian


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

[COMMITTERS] pgscript - pgScript: Updated documentation and TODO

Log Message:
-----------
Updated documentation and TODO

Modified Files:
--------------
pgScript/doc:
docbook.css (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/docbook.css.diff?r1=1.1&r2=1.2)
INDEX.html (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INDEX.html.diff?r1=1.1&r2=1.2)
INDEX.xml (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INDEX.xml.diff?r1=1.1&r2=1.2)
pgScript:
TODO (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/TODO.diff?r1=1.1&r2=1.2)

Removed Files:
-------------
pgScript/doc:
README
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/README)

--
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] freebsd + postgresql 8.3.3 = 100% of cpu usage on stats collector?

On Sat, 28 Jun 2008 11:35:24 +0200
hubert depesz lubaczewski <depesz@depesz.com> wrote:

> On Sat, Jun 28, 2008 at 02:22:26AM -0300, Rodrigo Gonzalez wrote:
> > So, read man page, and at least ktrace -C and read the output at
> > ktrace.out file.
>
> ok, i've read it and didn't understand. it says how to disable tracing
> but it doesn't say anything about enabling tracing.

Use "ktrace -p [pid]" to start tracing. Then use "ktrace -C" to stop
tracing. Trace data is dumped in binary format to the file ktrace.out
(unless you use the -f option to specify another file)

Use the kdump utility to convert the ktrace.out file to something usable.
Something like "kdump > ktrace.txt" will probably get you what you want,
assuming your ktrace file is ktrace.out.

--
Bill Moran <wmoran@collaborativefusion.com>

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

[COMMITTERS] pgsql: Remove unnecessary coziness of GIN code with datum copying.

Log Message:
-----------
Remove unnecessary coziness of GIN code with datum copying. Now that
space is tracked via GetMemoryChunkSpace, there's really no advantage
to duplicating datumCopy's innards here. This is one bit of my toast
indirection patch that should go in anyway.

Modified Files:
--------------
pgsql/src/backend/access/gin:
ginbulk.c (r1.11 -> r1.12)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gin/ginbulk.c?r1=1.11&r2=1.12)

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

[HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

Attached is a worked-out patch for the approach proposed here:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00777.php
namely, that cache management for de-TOASTed datums is handled
by TupleTableSlots.

To avoid premature detoasting of values that we might never need, the
patch introduces a concept of an "indirect TOAST pointer", which has
the same 0x80 or 0x01 header as an external TOAST pointer, but can
be told apart by having a different length byte. Within that we have
* pointer to original toasted field within the Slot's tuple
* pointer to the owning Slot
* pointer to decompressed copy, or NULL if not decompressed yet
Some fairly straightforward extensions to the TupleTableSlot code,
heaptuple.c, and tuptoaster.c make it all go.

My original thoughts had included turning FREE_IF_COPY() into a no-op,
but on investigation that seems impractical. One case that still
depends on that pfree is where we have palloc'd a 4-byte-header copy
of a short-header datum to support code that needs properly aligned
datum content. The solution adopted in the patch is to arrange for
pfree() applied to a cacheable detoasted object to be a no-op, whereas
it still works normally for non-cached detoasted objects. We do this
by inserting a dummy chunk header that points to a dummy memory context
whose pfree support method does nothing. I think this part of the patch
would be required for any toast caching method, not just this one.

What I like about this patch is that it's a fairly small-footprint
change, it doesn't add much overhead, and it covers caching of
decompression for in-line-compressed datums as well as the out-of-line
case.

One thing I really *don't* like about it is that it requires everyplace
that copies Datums to know about indirect pointers: in general, the copy
must be a copy of the original toasted Datum, not of the indirect
pointer, else we have indirect pointers that can outlive their owning
TupleTableSlot (or at least outlive its current tuple cycle). There
only seem to be about half a dozen such places in the current code,
but still it seems a rather fragile coding rule.

After playing with it for a little bit, I'm not convinced that it buys
enough performance win to be worth applying --- the restriction of cache
lifespan to one tuple cycle of a TupleTableSlot is awfully restrictive.
(For example, sorts that involve toasted sort keys continue to suck,
because the tuples being sorted aren't in Slots.) It would probably
fix the specific case that the PostGIS hackers were complaining of,
but I think we need something more.

Still, I wanted to get it into the archives because the idea of indirect
toast pointers might be useful for something else.

regards, tom lane

Re: [pgsql-es-ayuda] Postgres y jdbc

La pregrunta es si es posible de enviar md5 en una cadena de conección con postgresql-8.2-508.jdbc4?

----- Mensaje original ----
De: Neil Peter Braggio <pbraggio@gmail.com>
Para: lennin.caro@yahoo.com
CC: lista postgres <pgsql-es-ayuda@postgresql.org>; Edgar Enriquez <edgarpostgres@yahoo.es>
Enviado: sábado, 28 de junio, 2008 13:28:03
Asunto: Re: Postgres y jdbc

Me gustaría saber como haces para _desencriptar_ (descifrar es la
palabra correcta) una cadena de caracteres obtenida de la salida de
una función MD5.

Me explico mejor: quisiera saber como obtienes la cadena original a
partir de una cadena MD5 obtenida por una función MD5.

----
Neil Peter Braggio
pbraggio@gmail.com


On Sat, Jun 28, 2008 at 9:58 AM, Lennin Caro <lennin.caro@yahoo.com> wrote:
> puedes hacer que el password exista en un archivo de texto, este password lo
> puedes encriptar con md5 y desencriptar en tu aplicacion al momento de
> pasarlo al  getConnection.
>
> La otra opcion es que lo introduzcan desde una ventana o directamente como
> parametro al llamar la aplicacion..
>
> --- On Fri, 6/27/08, Edgar Enriquez <edgarpostgres@yahoo.es> wrote:
>
> From: Edgar Enriquez <edgarpostgres@yahoo.es>
> Subject: [pgsql-es-ayuda] Postgres y jdbc
> To: "lista postgres" <pgsql-es-ayuda@postgresql.org>
> Date: Friday, June 27, 2008, 1:37 PM
>
> Saludos amigos de la lista, yo tengo un problema y es que no se como hacer
> para conectar una aplicacion java a posgres utilizando jdbc,
> postgresql-8.2-508.jdbc4, sin tener nececidad de guardar el pasword del
> usuario, yo utilizo este codigo
>
> try{
>                Class.forName("org.postgresql.Driver");
>                con =
> DriverManager.getConnection("jdbc:postgresql://192.168..100.126:5432/Migration","migration","swing");
>
>                System.out.println("PostgreSQL OK");
>            }
>            catch(Exception e){
>                System.out.println(URL+" "+utilisateur+" "+motDePass);
>                  System.out.println("No se ha podido cargar el Driver
> PostgreSQL");
>                  erreur = 1;
>                }
>
> el problema es que estoy obligado de guardar el nombre de usuario
> "migration" y el password "swing" en la aplicacion, alguien tiene una
> sugerencia?
>
> Nota: esta es una aplicacion para poder migrar ciertos datos de una base a
> otra pero necesito que sea transparente al usuario, la base de datos
> migracion me sirve de control, osea yo no quiero que el usuario sepa que se
> está conectando a una base de datos donde estoy controlando lo que hace ya
> que trabajo con gente que quiere mostrar que pasar de multiples bases de
> datos access(una por cliente) a una sola base en posgres no es factible
>
>
> Gracias
>
> ________________________________
> Enviado desde Correo Yahoo!
> La bandeja de entrada más inteligente.
>
>



Enviado desde Correo Yahoo!
La bandeja de entrada más inteligente..

Re: [HACKERS] TODO item: Allow data to be pulled directly from indexes

Gregory Stark wrote:
>> (1) & (4) require an UPDATE or DELETE to twiddle the old index tuple. Tom has
>> noted (in the linked message) that this is not reliable if the index has any
>> expression-valued columns, because it is not always possible to find the old
>> index entry. For this reason, the proposed patch does not keep visibility
>> metadata for indexes on expressions. This seems like a reasonable limitation
>> --- indexed expressions are just less efficient.
>>
>
> Or if the index operators and btproc aren't nearly as immutable as they claim.
> Probably less likely than non-immutable index expressions but also possible.
>
>
Your point is well taken... I'll have to look into that more.

>> (2) & (3) can work for any index, and they are quite elegant in the way that
>> the overhead does not change with the number of indexes. The TODO also notes
>> the benefit of (2) for efficient vacuuming. Thus, I think that (2) is a great
>> idea in general, but it does not serve the intended purpose of this TODO item.
>> Once a page gets marked as requiring visibility checks, it cannot be unmarked
>> until the next VACUUM. The whole point of this feature is that we are willing
>> to be more proactive during updates in order to make index access more
>> efficient.
>>
>
> Well I think that's precisely the point. If you're trading off work done at
> update time against work done for index accesses then you're only going to win
> if the tuples are relatively static and have lots of accesses done against
> them between updates. In which case having the optimization only kick in when
> the page has been static for long enough that all the tuples are globally
> visible should be good enough
I really don't understand this point. The way I see the visibility map
working is as follows: we set a page to "requires visibility check" when
a tuple on the page is inserted, deleted, or non-HOT updated. If the
only modifications have been inserts, we can reset the status to "all
tuples visible" when these tuples become universally visible, which
matches your description. But in the presence of deletes and updates, we
can only reset the status of a page after a VACUUM (I know that dead HOT
tuples can be pruned without VACUUM, but I don't think that's the case
for indexed tuples). We can't reset the status earlier because we don't
know what indexes still have pointers to the dead tuples. So a page can
be static indefinitely (after a single modification) without ever
getting to enjoy the optimization.

This is a really important point, so please let me know if I'm missing
something.

Thanks for your response!
Karl

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

Re: [PERFORM] Sources of information about sizing of hardwares to run PostgreSQL

On Fri, 27 Jun 2008, Sérgio R F Oliveira wrote:

> I need to specify servers and storage to run PostgreSQL. Does anyone
> know any source of information (articles, presentations, books, etc.)
> which describes methods of hardware sizing for running a large
> PostgreSLQ installation?

There aren't any, just a fair number of people who know how to do it and
some scattered bits of lore on the subject. The quickest way to get some
sort of estimate that is actually useful is to create a small prototype of
some tables you expect will be the larger ones for the application, load
some data into them, measure how big they are, and then extrapolate from
there. I'm dumping links and notes on the subject of measurements like
that http://wiki.postgresql.org/wiki/Disk_Usage that should get you
started with such a simulation.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] A guide/tutorial to performance monitoring and tuning

On Fri, 27 Jun 2008, Nikhil G. Daddikar wrote:

> I have been searching on the net on how to tune and monitor performance of my
> postgresql server but not met with success. A lot of information is vague and
> most often then not the answer is "it depends".

That's because it does depend. I collect up the best of resources out
there and keep track of them at

http://wiki.postgresql.org/wiki/Performance_Optimization so if you didn't
find that yet there's probably some good ones you missed.

Right now I'm working with a few other people to put together a more
straightforward single intro guide that should address some of the
vagueness you point out here, but that's still a few weeks away from being
ready.

Monitoring performance isn't really covered in any of this though. Right
now the best simple solution out there is probably Nagios with the
PostgreSQL plug-in.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Re: [GENERAL] compiling, performance of PostGreSQL 8.3 on 64-bit processors

On Thu, 26 Jun 2008, Adam Rich wrote:

> Is there any benefit to running a 32-bit OS (rhel 5 in this case) on a
> server with more than 4 GB of memory?

If you have more than 3GB of memory, you should be using a 64-bit OS.
While theoretically the 32-bit code might be smaller which has some
advantages, in practice the 64-bit versions will be faster.

> For people with experience running postgresql on systems with 16+ GB of
> memory, what parameter settings have you found to be effective? (This
> would be a large database that's mostly read-only that we'd like to fit
> completely in memory)

Much larger values for shared_buffers and work_mem seem to be the most
effective way to use larger amounts of memory. For example, if you've got
1GB of RAM, it can be hard to allocate >15% of it to shared_buffers while
leaving enough enough RAM for OS-level operations, applications, etc.
But if you've got 16GB, a large read-only database might usefully set that
to 50% of RAM instead.

> Is it possible to backup (pg_dump) from a 32-bit OS to a 64-bit OS,
> or is a plain SQL dump necessary?

pg_dump is a plain SQL dump, it's just a program to make it easier to
generate them. You need to do this sort of dump/reload in order to
convert from a 32-bit to a 64-bit platform.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

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

Re: [HACKERS] TODO item: Allow data to be pulled directly from indexes

"Karl Schnaitter" <karlsch@soe.ucsc.edu> writes:

"Karl Schnaitter" <karlsch@soe.ucsc.edu> writes:

> (1) & (4) require an UPDATE or DELETE to twiddle the old index tuple. Tom has
> noted (in the linked message) that this is not reliable if the index has any
> expression-valued columns, because it is not always possible to find the old
> index entry. For this reason, the proposed patch does not keep visibility
> metadata for indexes on expressions. This seems like a reasonable limitation
> --- indexed expressions are just less efficient.

Or if the index operators and btproc aren't nearly as immutable as they claim.
Probably less likely than non-immutable index expressions but also possible.

> I should mention there is a major flaw in the patch, because it puts pointers
> to HOT tuples in the index, in order to capture the different transaction ids
> in the chain. I think this can be fixed by only pointing to the root of the HOT
> chain, and setting xmin/xmax to the entire range of transaction ids spanned by
> the chain. I'm not sure about all the details (the ctid and some other bits
> also need to be set).

I think you can think of a HOT chain as a single tuple. The xmin of the head
is the xmin of the chain and the xmax of the tail is the xmax of the chain.
The xmin/xmax of the intermediate versions are only interesting for
determining *which* of the HOT versions to look at, but the index pointer
points to the whole chain.

> (2) & (3) can work for any index, and they are quite elegant in the way that
> the overhead does not change with the number of indexes. The TODO also notes
> the benefit of (2) for efficient vacuuming. Thus, I think that (2) is a great
> idea in general, but it does not serve the intended purpose of this TODO item.
> Once a page gets marked as requiring visibility checks, it cannot be unmarked
> until the next VACUUM. The whole point of this feature is that we are willing
> to be more proactive during updates in order to make index access more
> efficient.

Well I think that's precisely the point. If you're trading off work done at
update time against work done for index accesses then you're only going to win
if the tuples are relatively static and have lots of accesses done against
them between updates. In which case having the optimization only kick in when
the page has been static for long enough that all the tuples are globally
visible should be good enough.

The case where index visibility info might win over a visibility map might be
if the tuples are being heavily updated by long-lived transactions. In which
case they never sit globally visible for very long but having the xmin/xmax in
the index might avoid having to do a heap access for tuples which haven't been
committed yet.

As you seem to realize there has been a lot of discussion in this area
already. The visibility map looks like a much more popular direction.


--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's RemoteDBA services!

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

Re: [pgadmin-support] Wish List Request: Tabbed SQL Query Window

On Sun, Jun 29, 2008 at 6:06 PM, Ryan Daniels <ryan.daniels@gmail.com> wrote:
>
> Dave,
>
> What if the per-text-coltrol tabs were at the bottom of the region, and the
> per-file tabs were at the top?

Not all OS's support that iirc (for example, Windows XP under uxtheme
if memory serves), but I don't think that's a showstopper - just
something to be aware of as it may be confusing without some
additional redesign.

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

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

Re: [pgadmin-support] Wish List Request: Tabbed SQL Query Window


Dave,

What if the per-text-coltrol tabs were at the bottom of the region, and the per-file tabs were at the top?

Ryan

On Thu, Jun 26, 2008 at 4:07 AM, Dave Page <dpage@pgadmin.org> wrote:
On Wed, Jun 25, 2008 at 11:09 PM, Guillaume Lelarge
<guillaume@lelarge.info> wrote:
> Ryan Daniels a écrit :
>>
>> I would like to request that the SQL query window have tabs so that you
>> can have multiple queries/files open in the same window.
>>
>
> I think it could be a great idea. Don't know if it's really feasible but I
> like the idea.

Seems like it would be a lot of work. You'd need to seperate all the
query code out into a seperate class that you could instantiate aas
required on new tabs, and modify all the window options such that they
affect all tabs, or work with just the selected one as appropriate
(think 'Show line endings' vs. 'EOL Mode).

It would also look pretty weird as we will be adding tabs to the text
control soon anyway to handle the query builder, so we'll end up with
two sets of tabs on a tabset.

I'm happy to review patches though if someone wants to put some effort into it.

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

Re: [BUGS] BUG #4271: dropped columns conflict with returning rules

"Alexey Bashtanov" <bashtanov@imap.cc> writes:
>> What did you do *exactly*?

> Here's the example of command sequence that lead to this error:

> luh=# create table foo(a int);
> CREATE TABLE
> luh=# alter TABLE foo add column b int;
> ALTER TABLE
> luh=# alter TABLE foo drop column b;
> ALTER TABLE
> luh=# alter TABLE foo add column c int;
> ALTER TABLE
> luh=# create table foo_child() inherits (foo);
> CREATE TABLE
> luh=# create or replace rule myrule as on insert to foo do instead
> insert into foo_child values(new.*) returning foo_child.*;
> ERROR: cannot convert relation containing dropped columns to view

Ah, it looks like you get different errors depending on whether the
dropped column is the last one or not, but they're coming from the
same routine.

The short answer is that checkRuleResultList() isn't prepared to cope
with dropped columns. Per the code comment:

/*
* Disallow dropped columns in the relation. This won't happen in the
* cases we actually care about (namely creating a view via CREATE
* TABLE then CREATE RULE, or adding a RETURNING rule to a view).
* Trying to cope with it is much more trouble than it's worth,
* because we'd have to modify the rule to insert dummy NULLs at the
* right positions.
*/

This example shows that dropped columns might happen in real-world cases
after all, so I suppose we should think about improving the situation,
at least for the RETURNING case. (This comment was originally written
with only the convert-table-to-view case in mind, and I think it's still
a reasonable restriction there.)

Hmm, I wonder if "insert dummy NULLs" is really necessary, or if
renumbering the targetlist's resnos would be enough to make RETURNING
work? I forget whether we select RETURNING elements by resno or
physical position.

Anyway, I have other things to do that strike me as higher priority.
Anyone want to tackle this one?

regards, tom lane

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

Re: [BUGS] BUG #4271: dropped columns conflict with returning rules

Hello, Tom!

> What did you do *exactly*?

Here's the example of command sequence that lead to this error:

luh=# create table foo(a int);
CREATE TABLE
luh=# alter TABLE foo add column b int;
ALTER TABLE
luh=# alter TABLE foo drop column b;
ALTER TABLE
luh=# alter TABLE foo add column c int;
ALTER TABLE
luh=# create table foo_child() inherits (foo);
CREATE TABLE
luh=# create or replace rule myrule as on insert to foo do instead
insert into foo_child values(new.*) returning foo_child.*;
ERROR: cannot convert relation containing dropped columns to view
luh=#

> > this rule started to work incorrectly: it did not store foo and quackquack
> > values but used nulls instead.
>
> This is expected behavior because the * expressions are expanded when
> the rule is defined:

That's OK

Thanks,
Alexey

--

http://www.fastmail.fm - The way an email service should be


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

[BUGS] BUG #4274: uuid returns duplicate values

The following bug has been logged online:

Bug reference: 4274
Logged by: eric melbardis
Email address: eric.melbardis@netkitsolutions.com
PostgreSQL version: 8.3.3
Operating system: windows xp sp3
Description: uuid returns duplicate values
Details:

the uuid functions do not return unique values if used sequntially, or i
believe without too much tme in between invocations.

the following test functions returns the same value!

------------ test function ---------------
create or replace function test_uuid()
returns varchar as
$body$
begin
raise notice 'uuid = %', uuid_generate_v4();
raise notice 'uuid = %', uuid_generate_v4();
raise notice 'uuid = %', uuid_generate_v4();
raise notice 'uuid = %', uuid_generate_v4();
end;
$body$
language 'plpgsql' ;

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

Re: [GENERAL] LDAP Authentication

Taha Ozket wrote:
> Hi,
>
> I have a ldap group, "pgsql-developers". I have an user (user1) member
> of this group;
>
> group
> dn: cn=pgsql-developers,ou=Groups,o=Dep,dc=x,dc=x,dc=x
> objectClass: groupOfUniqueNames
> objectClass: top
> cn: SVN Committers
> uniqueMember: uid=user1,ou=Users,o=Dep,dc=x,dc=x,dc=x
>
> user
> dn: uid=user1,ou=Users,o=Dep,dc=x,dc=x,dc=x
> objectClass: person
> objectClass: top
> objectClass: uidObject
> cn:: Denem1
> sn:: Deneme2
> uid: user1
> userPassword:: e01ENX10WnhudnhscVIxZ1pIa0wzWm5ET3VnPT0=
>
> I added this line to pg_hba.conf [1]
>
> host all all 172.20.0.0/16 ldap
> "ldap://localhost/basedn;cn=;,cn=pgsql-developers,ou=Groups,o=Dep,dc=x,dc=x,dc=x"
>
> But now postgresql requires my user1 must be define under
> cn=pgsql-developers,ou=Groups.. But I want to give login permission to
> pgsql-developers members.
>
> How can I change this line for give login permission to
> pgsql-developers members?

This is not something you currently can do. We can only do LDAP
authentication, not authorization. There's no way to restrict it to a
particular group.

One way to accomplish what you're trying to do is to have a script that
synchronizes the members of the group to PostgreSQL accounts (account
name and role membership only), and still use LDAP for authentication.
It doesn't work in every case, but it does work in most.

//Magnus

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

Re: [BUGS] BUG #4271: dropped columns conflict with returning rules

"Alexey Bashtanov" <bashtanov@imap.cc> writes:
> I have created a partitioned table cache with partitions cache_id_g_4184088
> and cache_id_le_4184088 those inherit cache.
> I provided insert by the following rule:
> CREATE RULE cache_partic AS ON INSERT TO cache DO INSTEAD INSERT INTO
> cache_id_g_4184088 VALUES (new.*) RETURNING cache_id_g_4184088.*;

> after I ran
> ALTER TABLE cache add column foo
> ALTER TABLE cache add column bar
> ALTER TABLE cache drop column bar
> ALTER TABLE cache add column quackquack

> this rule started to work incorrectly: it did not store foo and quackquack
> values but used nulls instead.

This is expected behavior because the * expressions are expanded when
the rule is defined:

regression=# create table foo(f1 int, f2 int, f3 int);
CREATE TABLE
regression=# create table foo1() inherits (foo);
CREATE TABLE
regression=# create rule redirect as on insert to foo do instead
insert into foo1 values(new.*) returning foo1.*;
CREATE RULE
regression=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer |
f2 | integer |
f3 | integer |
Rules:
redirect AS
ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3)
VALUES (new.f1, new.f2, new.f3)
RETURNING foo1.f1, foo1.f2, foo1.f3

regression=# alter table foo add column f4 int;
ALTER TABLE
regression=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer |
f2 | integer |
f3 | integer |
f4 | integer |
Rules:
redirect AS
ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3)
VALUES (new.f1, new.f2, new.f3)
RETURNING foo1.f1, foo1.f2, foo1.f3

Of course you can redefine the rule after adding a column:

regression=# create or replace rule redirect as on insert to foo do instead
insert into foo1 values(new.*) returning foo1.*;
CREATE RULE
regression=# \d foo
Table "public.foo"
Column | Type | Modifiers
--------+---------+-----------
f1 | integer |
f2 | integer |
f3 | integer |
f4 | integer |
Rules:
redirect AS
ON INSERT TO foo DO INSTEAD INSERT INTO foo1 (f1, f2, f3, f4)
VALUES (new.f1, new.f2, new.f3, new.f4)
RETURNING foo1.f1, foo1.f2, foo1.f3, foo1.f4


> When I tried to ReCREATE this rule, POSTGRESQL said 'ERROR: cannot convert
> relation containing dropped columns to view'

What did you do *exactly*? I tried

regression=# alter table foo add column f5 int;
ALTER TABLE
regression=# alter table foo drop column f5;
ALTER TABLE
regression=# create or replace rule redirect as on insert to foo do instead
insert into foo1 values(new.*) returning foo1.*;
ERROR: RETURNING list has too few entries

which does seem like a bug but it's not what you are describing.

regards, tom lane

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

Re: [pgeu-general] European Agenda ?

Hello,

On Sat, Jun 21, 2008 at 01:36:15PM +0200, damien clochard wrote:
>
> Now i'm sure we can do better. This is just a "quick and naïve" proposal.
> Feel free to modify or criticize this page. I know that some might find this
> initiative is redundant with :
>
> http://www.postgresql.org/about/eventarchive

i agree with Koen: we can categorize the events on the main website.
Having two websites for events is double effort.


> Speaking of my own little person, as i don't take airplanes, i'm very little
> concerned by events organized outside Europe and i find it useful to have an
> european-speciifc event page.

You could swim or take a submarine *smile*

We should use our wiki only for european-only things like organizing the
events - but we don't reach the visitors, if every user group starts his
own website. In addition there's the possibility that two events take
place the same time because nobody knows all events.


> My guess is that having this page on the european wiki, will make things
> easier to edit and update.

Why not put the effort in categorizing the main wiki?


Kind regards

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group

[COMMITTERS] pgscript - pgScript: Added windows.sh for generating a Windows binary

Log Message:
-----------
Added windows.sh for generating a Windows binary package

Modified Files:
--------------
pgScript:
autofind.sh (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/autofind.sh.diff?r1=1.2&r2=1.3)
.cvsignore (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/.cvsignore.diff?r1=1.1&r2=1.2)
Makefile.am (r1.2 -> r1.3)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/Makefile.am.diff?r1=1.2&r2=1.3)
pgScript/lib:
.cvsignore (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/.cvsignore.diff?r1=1.1&r2=1.2)

Added Files:
-----------
pgScript:
windows.sh (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/windows.sh?rev=1.1&content-type=text/x-cvsweb-markup)
pgScript/lib:
config.h.in (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/config.h.in?rev=1.1&content-type=text/x-cvsweb-markup)

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

Re: [ADMIN] Warm standby server

Scott & Montaseri,

Montaseri wrote:
> While I am not an expert on WAL, but again I question the merits of
> such sophisticated HA configuration. Of course there are use cases for
> such configs, but I am only advocating best price performance kind of
> mentality
>
> As WAL writes the journals all the way down to the disk (ie write thru
> and not write behind) before ack-ing toward the next step in a DB
> operation, increasing the number of mirrors (one production, one
> on-site, one off-site, I count 3 plexes here) will prolong each
> operation, with the following exponentially increasing write latencies
"traditional" warm-standby involves replicating the *archived* (read:
not currently-in-use) WAL to the standby servers, something that doesn't
require a synchronous write operation, and something that could be
spread out over a period of time. However, you might have an issue if
the system copies across WAL's slower than new ones are generated.

Scott, you should be aware that the mechanism you are proposing has the
potential to "lose" the transactions that had committed, but had not yet
been archived. That would most likely be the changes in the "currently
being written" WAL file - which hadn't been filled up, and thus had not
yet been archived.

For your colo standby server, you might consider using some synchronous
mechanism for WAL storage. Such a mechanism would have an impact on
server performance but would allow you to achive durability of committed
transactions. I'll actually be talking a bit about this at the PGDay of
Linux World (August 5th)...

--
Chander Ganesan
Open Technology Group, Inc.
One Copley Parkway, Suite 210
Morrisville, NC 27560
919-463-0999/877-258-8987
http://www.otg-nc.com
Ask me about Expert PostgreSQL, PostGIS, and other Open Source training.

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

[GENERAL] LDAP Authentication

Hi,

I have a ldap group, "pgsql-developers". I have an user (user1) member
of this group;

group
dn: cn=pgsql-developers,ou=Groups,o=Dep,dc=x,dc=x,dc=x
objectClass: groupOfUniqueNames
objectClass: top
cn: SVN Committers
uniqueMember: uid=user1,ou=Users,o=Dep,dc=x,dc=x,dc=x

user
dn: uid=user1,ou=Users,o=Dep,dc=x,dc=x,dc=x
objectClass: person
objectClass: top
objectClass: uidObject
cn:: Denem1
sn:: Deneme2
uid: user1
userPassword:: e01ENX10WnhudnhscVIxZ1pIa0wzWm5ET3VnPT0=

I added this line to pg_hba.conf [1]

host all all 172.20.0.0/16 ldap
"ldap://localhost/basedn;cn=;,cn=pgsql-developers,ou=Groups,o=Dep,dc=x,dc=x,dc=x"

But now postgresql requires my user1 must be define under
cn=pgsql-developers,ou=Groups.. But I want to give login permission to
pgsql-developers members.

How can I change this line for give login permission to
pgsql-developers members?

[1] http://wiki.postgresql.org/wiki/LDAP_Authentication_against_AD

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

Re: [pgsql-es-ayuda] Retorno de tipo boolean

El día 29 de junio de 2008 0:24, Eduardo Villagrán Morales
<eduardo.villagran.morales@gmail.com> escribió:
> Hola a todos,
> quisiera saber si existe alguna forma de retornar los booleans con su
> valor entero (0,1) en vez de 't' o 'f'.
>
> Gracias
> --
> Eduardo Villagrán Morales
> Alumno memorista
> Usach
>

Podes hacer una vista
create view as nomvista as
select codigo, case when campoboolean then 1 else 0 end as marca
from ....

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

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

"Ulrich" <ulrich.mierendorff@gmx.net> writes:

> Hi,
> Yes that looks strange. But it is not possible that I have processors in
> "users_processors" which do not appear in "processors", because
> "users_processors" contains foreign keys to "processors".
>
> If I remove the LIMIT 10 OFFSET 1 the line "Sort (cost=.... rows=11.."
> disappears and the query return 13 correct processors from "processors".

Oh, er, my bad. That makes perfect sense. The "actual" numbers can be affected
by what records are actually requested. The LIMIT prevents the records beyond
11 from ever being requested even though they exist.

While the bitmap heap scan has to fetch all the records even though they don't
all get used, the nested loop only fetches the records as requested.

--
Gregory Stark
EnterpriseDB

http://www.enterprisedb.com

Ask me about EnterpriseDB's PostGIS support!

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

[HACKERS] TODO item: Allow data to be pulled directly from indexes

Sometime last year, a discussion started about including visibility
metadata to avoid heap fetches during an index scan:

http://archives.postgresql.org/pgsql-patches/2007-10/msg00166.php
http://archives.postgresql.org/pgsql-patches/2008-01/msg00049.php

I think the last discussion on this was in April:

http://archives.postgresql.org/pgsql-hackers/2008-04/msg00618.php (last
item)

I have worked with the current patch, and I have some thoughts about
that approach and the approaches listed in the TODO item. The TODO lists
three approaches, in short

(1) Add a bit for an index tuple that indicates "visible" or "maybe
visible."
(2) Use a per-table bitmap that indicates which pages have at least one
tuple that is not visible to all transactions.
(3) Same as (2) but at the granularity of one bit per table.

The approach in the patch is different:

(4) Add transaction ids, etc to the index tuple (totaling 16 bytes)

I would group (1) & (4) together and (2) & (3) together. I think the
time and space trade-offs are pretty obvious, so I won't waste time on
those.

(1) & (4) require an UPDATE or DELETE to twiddle the old index tuple.
Tom has noted (in the linked message) that this is not reliable if the
index has any expression-valued columns, because it is not always
possible to find the old index entry. For this reason, the proposed
patch does not keep visibility metadata for indexes on expressions. This
seems like a reasonable limitation --- indexed expressions are just less
efficient.

The main difference between (1) & (4) is that (1) will sometimes require
heap lookups and (4) never will. Moreover, the heap lookups in (1) will
be difficult for the optimizer to estimate, unless some special
statistics can be maintained for this purpose.

I should mention there is a major flaw in the patch, because it puts
pointers to HOT tuples in the index, in order to capture the different
transaction ids in the chain. I think this can be fixed by only pointing
to the root of the HOT chain, and setting xmin/xmax to the entire range
of transaction ids spanned by the chain. I'm not sure about all the
details (the ctid and some other bits also need to be set).

(2) & (3) can work for any index, and they are quite elegant in the way
that the overhead does not change with the number of indexes. The TODO
also notes the benefit of (2) for efficient vacuuming. Thus, I think
that (2) is a great idea in general, but it does not serve the intended
purpose of this TODO item. Once a page gets marked as requiring
visibility checks, it cannot be unmarked until the next VACUUM. The
whole point of this feature is that we are willing to be more proactive
during updates in order to make index access more efficient.

So in summary, I think that (2) would be nice as a separate feature,
with (1) and (4) being more favorable for index-only scans. The obvious
trouble with (4) is the extra space overhead. There are also issues with
correctness that I mentioned (any thoughts here would be appreciated).
Other than that, I would favor (4) because it offers the most stable
performance.

Please let me know if you agree/disagree with anything here. I need to
get this feature implemented for my research, but I would also love to
contribute it to the community so your opinions matter a lot.


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

[COMMITTERS] pgscript - pgScript: Added cvsignore for documentation

Log Message:
-----------
Added cvsignore for documentation

Added Files:
-----------
pgScript/doc:
.cvsignore (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/.cvsignore?rev=1.1&content-type=text/x-cvsweb-markup)

Removed Files:
-------------
pgScript/doc:
Makefile.in
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/Makefile.in)
Makefile
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/Makefile)

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

[COMMITTERS] pgscript - pgScript: Added documentation and man page

Log Message:
-----------
Added documentation and man page

Modified Files:
--------------
pgScript/src:
Makefile.am (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/src/Makefile.am.diff?r1=1.1&r2=1.2)
pgsMain.cpp (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/src/pgsMain.cpp.diff?r1=1.1&r2=1.2)
pgScript/lib/include/pgscript:
parser.tab.hh (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/include/pgscript/parser.tab.hh.diff?r1=1.1&r2=1.2)
pgScript/test:
pgsTestSuite.cpp (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/test/pgsTestSuite.cpp.diff?r1=1.1&r2=1.2)
pgScript:
configure.ac (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/configure.ac.diff?r1=1.1&r2=1.2)
README (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/README.diff?r1=1.1&r2=1.2)
autofind.sh (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/autofind.sh.diff?r1=1.1&r2=1.2)
Makefile.am (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/Makefile.am.diff?r1=1.1&r2=1.2)
pgScript/files/tests/sources:
generators.sql.pgs (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/files/tests/sources/generators.sql.pgs.diff?r1=1.1&r2=1.2)
pgScript/files/inputs:
test.pgs (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/files/inputs/test.pgs.diff?r1=1.1&r2=1.2)
pgScript/lib/pgscript/expressions:
pgsExecute.cpp (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/pgscript/expressions/pgsExecute.cpp.diff?r1=1.1&r2=1.2)
pgScript/lib/pgscript:
parser.tab.cc (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/pgscript/parser.tab.cc.diff?r1=1.1&r2=1.2)
pgsParser.yy (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/pgscript/pgsParser.yy.diff?r1=1.1&r2=1.2)
lex.pgs.cc (r1.1 -> r1.2)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/lib/pgscript/lex.pgs.cc.diff?r1=1.1&r2=1.2)

Added Files:
-----------
pgScript/src:
pgScript.1 (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/src/pgScript.1?rev=1.1&content-type=text/x-cvsweb-markup)
pgScript/doc:
DEVELOPERS.xml (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/DEVELOPERS.xml?rev=1.1&content-type=text/x-cvsweb-markup)
INDEX.xml (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INDEX.xml?rev=1.1&content-type=text/x-cvsweb-markup)
INSTALL.xml (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INSTALL.xml?rev=1.1&content-type=text/x-cvsweb-markup)
generate.sh (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/generate.sh?rev=1.1&content-type=text/x-cvsweb-markup)
SCRIPT.html (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/SCRIPT.html?rev=1.1&content-type=text/x-cvsweb-markup)
SCRIPT.xml (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/SCRIPT.xml?rev=1.1&content-type=text/x-cvsweb-markup)
Makefile.in (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/Makefile.in?rev=1.1&content-type=text/x-cvsweb-markup)
DEVELOPERS.html (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/DEVELOPERS.html?rev=1.1&content-type=text/x-cvsweb-markup)
Makefile (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/Makefile?rev=1.1&content-type=text/x-cvsweb-markup)
Makefile.am (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/Makefile.am?rev=1.1&content-type=text/x-cvsweb-markup)
README (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/README?rev=1.1&content-type=text/x-cvsweb-markup)
INDEX.html (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INDEX.html?rev=1.1&content-type=text/x-cvsweb-markup)
docbook.css (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/docbook.css?rev=1.1&content-type=text/x-cvsweb-markup)
USAGE.html (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/USAGE.html?rev=1.1&content-type=text/x-cvsweb-markup)
USAGE.xml (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/USAGE.xml?rev=1.1&content-type=text/x-cvsweb-markup)
INSTALL.html (r1.1)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pgscript/pgScript/doc/INSTALL.html?rev=1.1&content-type=text/x-cvsweb-markup)

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

Re: [PERFORM] Subquery WHERE IN or WHERE EXISTS faster?

Hi,
Yes that looks strange. But it is not possible that I have processors in
"users_processors" which do not appear in "processors", because
"users_processors" contains foreign keys to "processors".

If I remove the LIMIT 10 OFFSET 1 the line "Sort (cost=.... rows=11.."
disappears and the query return 13 correct processors from "processors".
Then, I have tested different values for OFFSET. If I set Offset to "2"
and LIMIT=10 the line is:
Sort (cost=113.73..113.75 rows=8 width=5) (actual
time=0.322..0.330 rows=12 loops=1)
If I set Offset to "3" and LIMIT=10 it is
Sort (cost=113.73..113.75 rows=8 width=5) (actual
time=0.321..0.328 rows=13 loops=1)

It looks like if this "row" is something like min(max_rows=13,
LIMIT+OFFSET). But I do not completely understand the Syntax... ;-)

Kind regards
Ulrich

Gregory Stark wrote:
> "Ulrich" <ulrich.mierendorff@gmx.net> writes:
>
>
>> EXPLAIN ANALYZE SELECT speed FROM processors WHERE id IN (SELECT processorid
>> FROM users_processors WHERE userid=4040) ORDER BY speed ASC LIMIT 10 OFFSET 1;
>>
>> Limit (cost=113.73..113.75 rows=7 width=5) (actual time=0.335..0.340 rows=10 loops=1)
>> -> Sort (cost=113.73..113.75 rows=8 width=5) (actual time=0.332..0.333 rows=11 loops=1)
>>
>
> ^^
>
>
>> Sort Key: processors.speed
>> Sort Method: quicksort Memory: 17kB
>> -> Nested Loop (cost=47.22..113.61 rows=8 width=5) (actual time=0.171..0.271 rows=13 loops=1)
>> -> HashAggregate (cost=47.22..47.30 rows=8 width=4) (actual time=0.148..0.154 rows=13 loops=1)
>> -> Bitmap Heap Scan on users_processors (cost=4.36..47.19 rows=12 width=4) (actual time=0.074..0.117 rows=13 loops=1)
>>
>
> ^^
>
>
>> Index Cond: (userid = 4040)
>> -> Index Scan using processors_pkey on processors (cost=0.00..8.28 rows=1 width=9) (actual time=0.006..0.007 rows=1 loops=13)
>> Index Cond: (processors.id = users_processors.processorid)
>>
>
>
> It looks to me like you have some processors which appear in
> "users_processors" but not in "processors". I don't know your data model but
> that sounds like broken referential integrity to me.
>
>


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

Re: [CYGWIN] Updating postgres 7.4.5 to 8 via cygwin

Nick Texidor schrieb:
> I was wondering whether someone can help me. I already have postgres
> 7.4.5 running under cygwin on my web server, and I've looked into
> installing the native version of 8, but it looks like there is a bit of
> dumping/importing of database to be done. I noticed that postgres 8 is
> available under cygwin, and it came up as an update. If I install it
> through cygwin, is there any messing around with databases to be done?
> Is that an easier option than installing the native version and moving
> from a cygwin version?

Installing a native version will create a new database.
Upgrading cygwin to 8 will leave you with a non-accessible database.

So if you need the data from the old database, you MUST export it.

See the cygwin announcement, which describes it in detail.
http://article.gmane.org/gmane.os.cygwin.announce/2310

Which says:
Before you upgrade a postgresql package to a new new major or
minor version (7.4 => 8.0 => 8.1 => 8.2), be sure to dump all your data
before!
With the new package you will not be able to access your old databases.
=> http://www.postgresql.org/docs/8.2/static/app-pg-dumpall.html
Minor subrelease updates (e.g. 8.2.4 to 8.2.5) can safely access the
same database.
--
Reini Urban
http://phpwiki.org/

http://murbreak.at/

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

Re: [GENERAL] dblink to non postgresql dbms

2008/6/29 David Rowley <dgrowley@gmail.com>:
>
> I had forgotten to say before that my instance of postgresql is running on
> windows.
>
> I can't seem to find any evidence of freetds running on windows, I guess
> there is not a great deal of need since MS's native client is there. So I'm
> thinking of re-writing the dblink-tds to use Mircosoft's native client
> rather than tds. The odbclink does not have any files yet, but looks like
> exactly what I'd need.

You could also try dbi-link, it's in Perl so should be portable and
quite easy to rewrite.
Think of DBD::ODBC or DBD::ADO (the latter works for me with ActivePerl)


--
Filip Rembiałkowski

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

Re: [pgsql-it-generale] Float in java, come in Postgres?

On 23/giu/08, at 17:48, Stefano Tranquillini wrote:

> Salve,
> ho la necessità di salvare un float da java nel db e di ritirarlo
> su. Il tutto viene fatto attraverso ibatis.
> il problema è: che tipo di dato devo settare in Postgres? mi da
> sempre errore in fase di select. in fase di insert inserisce NULL.
> qualcuno sa aiutarmi?

No, sono anni che non lavoro in java, ma ci provo lo stesso ;-) Che
errore ti dà in select? Per l'insert sospetto che sia un problema di
ibatis, forse nella generazione dell'sql? Altrimenti non vedo da dove
possa arrivare il NULL…


--
Giorgio Valoti


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

Re: [pgadmin-hackers] Support for integrated tsearch configuration

Roberts, Jon a écrit :
>> On Sat, Jun 28, 2008 at 1:54 PM, Guillaume Lelarge
>>> Nothing is really simple on pgAdmin's coding (says the guy who tries
>> hardly
>>> to compile it under Windows since last evening... grmbl... :) ).
>> That shouldn't be hard - what was the problem?
>
>
> You really think so? Getting pgAdmin to compile in Windows is very
> difficult. I thought it was done on purpose to make people dislike
> Windows.
>

I won't go as far as Jon, but it sure isn't easy. At least, for me.

But anyways, it works now ;) And I see your issue with my patch. I'll
work on it quite soon.


--
Guillaume.

http://www.postgresqlfr.org

http://dalibo.com

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

[CYGWIN] Updating postgres 7.4.5 to 8 via cygwin

Hi,

I was wondering whether someone can help me.   I already have postgres 7.4.5 running under cygwin on my web server, and I've looked into installing the native version of 8, but it looks like there is a bit of dumping/importing of database to be done.   I noticed that postgres 8 is available under cygwin, and it came up as an update.  If I install it through cygwin, is there any messing around with databases to be done?  Is that an easier option than installing the native version and moving from a cygwin version?

Thank you

Nick


Re: [pgsql-es-ayuda] Retorno de tipo boolean

El día 28 de junio de 2008 23:24, Eduardo Villagrán Morales
<eduardo.villagran.morales@gmail.com> escribió:
> Hola a todos,
> quisiera saber si existe alguna forma de retornar los booleans con su
> valor entero (0,1) en vez de 't' o 'f'.

En la configuració no se, pero lo podrias hacer así.

Select
case
when columabooleana is true then 1 else 0
end as columnaboleana
from tutabla;

Espero que te sirva, Un abrazo
--
§~^Calabaza^~§ from Villa Elisa, Paraguay
--
TIP 7: no olvides aumentar la configuración del "free space map"