Wednesday, July 16, 2008

Re: [HACKERS] avoid recasting text to tsvector when calculating selectivity

Jan UrbaƄski wrote:
> Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl>
>> writes:
>>> I'm about to write a oprrest function for the @@ operator. Currently
>>> @@ handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
>>> tsquery @@ tsvector etc. The text @@ text case is for instance
>>> handled by calling to_tsvector and plainto_tsquery on the input
>>> arguments.
>>
>>> For a @@ restriction function, I need to have a tsquery and a
>>> tsvector, so in the text @@ text situation I'd end up calling
>>> plainto_tsquery during planning, which would consequently get called
>>> again during execution. Also, I'd need a not-so-elegant
>>> if-elsif-elsif sequence at the beginning of the function. Is this
>>> OK/unavoidable/easly avoided?
>>
>> I'm not following your point here. Sure, there are multiple flavors of
>> @@, but why shouldn't they each have their own oprrest function?
>
> Because they'll all boil down to the same function. Suppose I have an
> oprrest function for tsvector @@ tsquery. An oprrest for text @@ text
> would just be:
> tv = DatumGetTSVector(DirectFunctionCall1(to_tsvector,
> PG_GETARG_DATUM(0)));
> tq = DatumGetTSQuery(DirectFunctionCall1(plainto_tsquery,
> PG_GETARG_DATUM(1)));
> res = DirectFunctionCall2(my_oprrest, TSVectorGetDatum(tv),
> TSQueryGetDatun(tq))
> ...
>
> I thought I might avoid having to call ts_tsvector and plainto_tsquery,
> because the arguments need to be transformed to tsvector and tsquery
> anyway during execution.

[thinks...]
OTOH, you often plan a query without executing it, so this doesn't make
sense. OK, please disregard that, I'm just beginning to see the depths
of my misunderstanding of the issue ;)

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin


--
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] avoid recasting text to tsvector when calculating selectivity

Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl> writes:
>> I'm about to write a oprrest function for the @@ operator. Currently @@
>> handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
>> tsquery @@ tsvector etc. The text @@ text case is for instance handled
>> by calling to_tsvector and plainto_tsquery on the input arguments.
>
>> For a @@ restriction function, I need to have a tsquery and a tsvector,
>> so in the text @@ text situation I'd end up calling plainto_tsquery
>> during planning, which would consequently get called again during
>> execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at
>> the beginning of the function. Is this OK/unavoidable/easly avoided?
>
> I'm not following your point here. Sure, there are multiple flavors of
> @@, but why shouldn't they each have their own oprrest function?

Because they'll all boil down to the same function. Suppose I have an
oprrest function for tsvector @@ tsquery. An oprrest for text @@ text
would just be:
tv = DatumGetTSVector(DirectFunctionCall1(to_tsvector, PG_GETARG_DATUM(0)));
tq = DatumGetTSQuery(DirectFunctionCall1(plainto_tsquery,
PG_GETARG_DATUM(1)));
res = DirectFunctionCall2(my_oprrest, TSVectorGetDatum(tv),
TSQueryGetDatun(tq))
...

I thought I might avoid having to call ts_tsvector and plainto_tsquery,
because the arguments need to be transformed to tsvector and tsquery
anyway during execution.

--
Jan Urbanski
GPG key ID: E583D7D2

ouden estin

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

Re: [SQL] PERSISTANT PREPARE (another point of view)

Hello

2008/7/16 Milan Oparnica <milan.opa@gmail.com>:
> Milan Oparnica wrote:
>>
>> It's simply to complicated to return recordsets through server-side stored
>> procedures. They are obviously designed to do complex data manipulation,
>> returning few output variables informing the caller about final results.
>> Returning records through sets of user-defined-types is memory and
>> performance waste (please see my previous post as reply to Steve for more
>> details). Plus it's hard to maintain and make improvements to such a system.
>> I hate to see 800 user types made for every query we made as stored
>> procedure.
>
> Is this topic completely out of scope in Postgre ?
> If I'm missing something too obvious or too important, please let me know
> what.
>
> I run over and over through internet and Postgre documentation and still
> found nothing.
>

try to write prototype and show advantages. I am able to undestand
advantages of persistent prep. stamenents, but I see some disadvatage
too. Mainly you have to manage some shared memory space for stored
plans. It's not easy task - MySQL develepoers can talk. Implemenation
on postgresql is little bit dificult - lot of structures that lives in
processed memory have to be moved to shared memory.

This feature is nice, but question is - who do write it? Actually this
problem is solved from outside - with pooling.

Regards
Pavel Stehule

> Is there a better place to communicate with Postgre developers ?
>
> Sincerely,
>
> Milan Oparnica
>
> --
> Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-sql
>

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

[pgadmin-support] pgadmin doesn't show field contents

Dear List

We have databases in SQL_ASCII (I know, uft-8 would be better).
In Windows, pgadmin works fine.
In Ubuntu, pgadmin doesn't show field content when fields contain
special characters such aus umlaute.

Is this a bug, and is there a workaround (other than changing the
encoding of the db?)

Many thanks for any help
best regards
pl


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

Re: [HACKERS] Postgres-R source code release

On Wed, Jul 16, 2008 at 09:35:28PM +0200, Markus Schiltknecht wrote:
> Hi,
>
> David Fetter wrote:
>> Would you mind if I were to make a git branch for it on
>> <http://git.postgresql.org/> ?
>
> I've set up a git-daemon with the Postgres-R patch here:
>
> git://postgres-r.org/repo
>
> Since it's a distributed VCS, you should be able to mirror that to
> git.postgtresql.org somehow (if you figure out how, please tell me!).

I've merged the latest Postgres in. Care to see whether it runs?
http://git.postgresql.org/?p=~davidfetter/pgr/.git;a=summary

> Please note that I'm still struggling with git and I cannot promise
> to keep using it.

I'm struggling, too, but the cheapness of experimenting is making it
easier and easier :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
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: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

Hi Simon,

On Thu, Jul 17, 2008 at 4:36 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
> On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> > TRUNCATE foo;
> > TRUNCATE foo;
> >
> > works well.
> >
> > So why do we need
> >

I presented a simple psql version here. I was actually processing multiple relations in my C library in which truncate was invoked on all the involved relations. I was passing a list of these rels to ExecuteTruncate which barfed when the same rel was mentioned twice in that list. Its really an implementation issue as Tom mentioned.

Regards,
Nikhils
 

> >  TRUNCATE foo, foo;
>
> For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
> rather inconsistent.

Inconsistent with what exactly?

If a proposal to support this was made on hackers, it would be laughed
away. It is not required for functionality, usability, standards
compliance, backwards compatibility, robustness, performance, internal
coding simplicity, portability, marketing or external compatibility. For
what reason would we do it? Nobody has said.

And as I pointed out, other commands fail in similar circumstances.

Consistency is required, but consistency in making balanced judgements
about feature additions.

Our users will be surprised to find this was at the top of our list
ahead of other patches during a commit fest, other agreed TODO items and
other proposals from users.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


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



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

Re: [HACKERS] [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

Simon Riggs <simon@2ndquadrant.com> writes:
> On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
>> On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
>>> So why do we need
>>> TRUNCATE foo, foo;
>>
>> For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
>> rather inconsistent.

> Inconsistent with what exactly?

Well, it's certainly surprising that it fails entirely. And if we
actually wanted to reject the case, it should be drawing an apropos
error message. The fact is that this failure is just an implementation
issue.

> Our users will be surprised to find this was at the top of our list

If it had taken more than five lines of code to fix, I might agree with
you. But we don't stop fixing bugs just because commitfest is on,
especially not trivial ones.

regards, tom lane

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

Re: [HACKERS] avoid recasting text to tsvector when calculating selectivity

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <j.urbanski@students.mimuw.edu.pl> writes:
> I'm about to write a oprrest function for the @@ operator. Currently @@
> handles multiple cases, like tsvector @@ tsquery, text @@ tsquery,
> tsquery @@ tsvector etc. The text @@ text case is for instance handled
> by calling to_tsvector and plainto_tsquery on the input arguments.

> For a @@ restriction function, I need to have a tsquery and a tsvector,
> so in the text @@ text situation I'd end up calling plainto_tsquery
> during planning, which would consequently get called again during
> execution. Also, I'd need a not-so-elegant if-elsif-elsif sequence at
> the beginning of the function. Is this OK/unavoidable/easly avoided?

I'm not following your point here. Sure, there are multiple flavors of
@@, but why shouldn't they each have their own oprrest function?

regards, tom lane

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

Re: [JDBC] Problem with java infinity mapping to postgres real column type

Tom Lane wrote:
> Kris Jurka <books@ejurka.com> writes:
>> Actually the problem is:
>> jurka=# select 'infinity'::float8::float4;
>> ERROR: type "real" value out of range: overflow
>
> Well, that's definitely a problem, but what PG version are you testing
> on what platform? I get this using CVS HEAD on Fedora 9, Darwin, and
> HPUX:
>
> regression=# select 'infinity'::float8::float4;
> float4
> ----------
> Infinity
> (1 row)
>

I get the error (or variant) for 7.4 -> 8.2 on Debian Linux. 8.3 and
HEAD work.

I see this in the 8.3 release notes:

Fix float4/float8 to handle Infinity and NAN (Not A Number) consistently
(Bruce) The code formerly was not consistent about distinguishing
Infinity from overflow conditions.

Kris Jurka


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

Re: [JDBC] Problem with java infinity mapping to postgres real column type

Kris Jurka <books@ejurka.com> writes:
> Actually the problem is:
> jurka=# select 'infinity'::float8::float4;
> ERROR: type "real" value out of range: overflow

Well, that's definitely a problem, but what PG version are you testing
on what platform? I get this using CVS HEAD on Fedora 9, Darwin, and
HPUX:

regression=# select 'infinity'::float8::float4;
float4
----------
Infinity
(1 row)

I suspect that you aren't getting true "Infinity" from
'infinity'::float8 in the first place, but some large number,
which then fails to fit into float4.

regards, tom lane

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

[NOVICE] Stopping a transaction as soon as an error occurs

Hi list,

I am dumping a series of data. Basically I'm migrating the tables from one database to another. However, I wanted the transaction to stop immediately as soon as the error below occurs:

psql:gravy.all.schema.sql:142136: ERROR:  current transaction is aborted, commands ignored until end of transaction block

What happens is that it continues to do the transaction even if there's already a transaction and I'm having hard time catching it. I need to know which line number the error first occured so that  I can check my dump file and do the necessary remedy.


Thanks,

Ridvan


--
Laurence J. Peter  - "Originality is the fine art of remembering what you hear but forgetting where you heard it."

Re: [COMMITTERS] pgsql: Add URL for: * Implement SQL:2003 window functions > >

2008/7/17 Bruce Momjian <momjian@postgresql.org>:
> Log Message:
> -----------
> Add URL for:
>
> * Implement SQL:2003 window functions
>>
>> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00380.php
>>
>
> Modified Files:
> --------------
> pgsql/doc:
> TODO (r1.2489 -> r1.2490)
> (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?r1=1.2489&r2=1.2490)
> pgsql/doc/src/FAQ:
> TODO.html (r1.995 -> r1.996)
> (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html?r1=1.995&r2=1.996)
>
> --
> Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-committers
>

F.Y.I.
the subsequent discussion is here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg00232.php

Regards,

--
Hitoshi Harada

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

[pgadmin-support] Error connect on user other then postgres (in Sql Editor

In Sql query tools, you kill connect on user other then "postgres". I
don`t can connect on other user for test security system :(

Thanks

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

Re: [JDBC] Problem with java infinity mapping to postgres real column type

On Wed, 16 Jul 2008, Tom Lane wrote:

> It sounds like "infinity" is getting translated to "some large number"
> rather than the correct "Infinity" or "-Infinity" symbol. The latter
> two should work on IEEE-compliant platforms, but you might want to check
> manually:

Actually the problem is:

jurka=# select 'infinity'::float8::float4;
ERROR: type "real" value out of range: overflow

I would have expected that the float8 -> float4 conversion would just keep
it as infinity.

Kris Jurka

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

RE: [pgsql-es-ayuda] De informix a Postgresql

Si queres que corra en linux, con KDE o GNOME, te recomiendo Gambas.
Facil como visual basic, pero realmente orientado a objetos.
En la ultima version estable trae incluso un convertor de proyectos que algo funciona.

En windows Visual Basic, .net o VB6, depende tus clientes.

Atte.
Gabriel Colina


____________________________________________________________________________________
Yahoo! MTV Blog & Rock &gt;¡Cuéntanos tu historia, inspira una canción y gánate un viaje a los Premios MTV! Participa aquí http://mtvla.yahoo.com/
--
TIP 7: no olvides aumentar la configuración del "free space map"

Re: [GENERAL] Default fill factor for tables?

> I'm using 8.3.1 on Solaris and I just tried this:
> CREATE TABLE test (a int) WITH (hot_update='true');
>
> It fails with:
> ERROR: unrecognized parameter "hot_update"
>
> Is a hot update automatic in 8.3.x and that is why there isn't any
> formal documentation other than what is in the source code?

It's always on (you can't turn it off).

If you want to look at the tech side of things check out:

http://people.planetpostgresql.org/devrim/index.php?/archives/117-Looking-for-a-presentation-regarding-HOT.html

--
Postgresql & php tutorials
http://www.designmagick.com/

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

[HACKERS] small bug in hlCover

Index: src/backend/tsearch/wparser_def.c
===================================================================
RCS file: /home/postgres/devel/pgsql-cvs/pgsql/src/backend/tsearch/wparser_def.c,v
retrieving revision 1.15
diff -c -r1.15 wparser_def.c
*** src/backend/tsearch/wparser_def.c 17 Jun 2008 16:09:06 -0000 1.15
--- src/backend/tsearch/wparser_def.c 17 Jul 2008 02:45:34 -0000
***************
*** 1621,1627 ****
QueryItem *item = GETQUERY(query);
int pos = *p;

! *q = 0;
*p = 0x7fffffff;

for (j = 0; j < query->size; j++)
--- 1621,1627 ----
QueryItem *item = GETQUERY(query);
int pos = *p;

! *q = -1;
*p = 0x7fffffff;

for (j = 0; j < query->size; j++)
***************
*** 1643,1649 ****
item++;
}

! if (*q == 0)
return false;

item = GETQUERY(query);
--- 1643,1649 ----
item++;
}

! if (*q < 0)
return false;

item = GETQUERY(query);
I think there is a slight bug in hlCover function in wparser_def.c

If there is only one query item and that is the first word in the text,
then hlCover does not returns any cover. This is evident in this example
when ts_headline only generates the min_words:

testdb=# select ts_headline('1 2 3 4 5 6 7 8 9 10','1'::tsquery,
'MinWords=5');
ts_headline
------------------
<b>1</b> 2 3 4 5
(1 row)

The problem is that *q is initialized to 0 which is a legitimate value
for a cover. So I have attached a patch that fixes it and after applying
the patch here is the result.

testdb=# select ts_headline('1 2 3 4 5 6 7 8 9 10','1'::tsquery,
'MinWords=5');
ts_headline
-----------------------------
<b>1</b> 2 3 4 5 6 7 8 9 10
(1 row)

-Sushant.

Re: [pgsql-www] Spam filtering on the mailing lists

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I just cleared out the AWL ... going through the stuff label'd as 'non-spam',
am finding alot of stuff scoring a bit low due to the From being in AWL ...

Does anyone know if there is some 'rule' that return mail about 'Undeliverable'
has to be in English? I'm finding some that *look* like that sort of thing,
but in other languages / character sets, and wonder if there is an RFC that is
meant to direct such stuff 'in English'? (ie. should I be marking that stuff
as spam, since *I* can't confirm it isn't?)

- --On Wednesday, July 16, 2008 23:17:22 -0300 "Marc G. Fournier"
<scrappy@hub.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Its sad how this is such an ongoing problem, but this is the first that I
> hear that ppl are having problems ... looking at the message headers for a
> random few, I notice that they are scoring >4, but just below 5:
>
> X-Spam-Status: No, hits=4.855 tagged_above=0 required=5 tests=AWL=-1.994,
> DCC_CHECK=1.37, DIGEST_MULTIPLE=0.001, HTML_MESSAGE=0.001,
> MIME_HTML_ONLY=1.672, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188,
> RCVD_IN_SORBS_WEB=1.117
> X-Spam-Level: ****
>
> I can change the quarantining to be >4 if ppl want, which should greatly
> reduce the # of messages going through ...
>
> Thoughts?
>
> - --On Wednesday, July 16, 2008 14:07:38 -0400 Andrew Sullivan
> <ajs@commandprompt.com> wrote:
>
>> On Wed, Jul 16, 2008 at 10:01:13AM -0700, Joshua D. Drake wrote:
>>> I have just learned to overlook it.
>>
>> But moderators can't overlook it. We have to troll through piles of
>> it. Much of it is in Cyrillic or CJK, and is just obviously not aimed
>> at the list. We still have to process it.
>>
>> (I say "we" even though I am still unable to send mail from the
>> account I moderate from, and therefore can't do any useful
>> moderating.)
>>
>> A
>>
>> --
>> Andrew Sullivan
>> ajs@commandprompt.com
>> +1 503 667 4564 x104
>> http://www.commandprompt.com/
>>
>> --
>> Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-www
>
>
>
> - --
> Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
> Email . scrappy@hub.org MSN . scrappy@hub.org
> Yahoo . yscrappy Skype: hub.org ICQ . 7615664
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (FreeBSD)
>
> iEYEARECAAYFAkh+q7IACgkQ4QvfyHIvDvPYfQCfchdCwNpL+90T5maoAWZUZttL
> 97wAoLMRAkqfszOxXojM7YNbUIZBX5ug
> =9v1h
> -----END PGP SIGNATURE-----
>
>
> --
> Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-www

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkh+tfQACgkQ4QvfyHIvDvNU7wCg7XDKErTl3ebHhTeS2o6p6J5Y
CscAn1i0bEFAYnHqGTvWmE0XsqjImc+9
=KGUA
-----END PGP SIGNATURE-----


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

Re: [pgsql-www] Spam filtering on the mailing lists

On Wed, 2008-07-16 at 23:17 -0300, Marc G. Fournier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Its sad how this is such an ongoing problem, but this is the first that I hear
> that ppl are having problems ...

I can only assume you mean "this time".

Joshua D. Drake


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


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

Re: [PATCHES] pg_dump lock timeout

*** a/doc/src/sgml/ref/pg_dump.sgml
--- b/doc/src/sgml/ref/pg_dump.sgml
***************
*** 557,564 **** PostgreSQL documentation
This option disables the use of dollar quoting for function bodies,
and forces them to be quoted using SQL standard string syntax.
</para>
! </listitem>
! </varlistentry>

<varlistentry>
<term><option>--disable-triggers</></term>
--- 557,564 ----
This option disables the use of dollar quoting for function bodies,
and forces them to be quoted using SQL standard string syntax.
</para>
! </listitem>
! </varlistentry>

<varlistentry>
<term><option>--disable-triggers</></term>
***************
*** 588,593 **** PostgreSQL documentation
--- 588,605 ----
</varlistentry>

<varlistentry>
+ <term><option>--lock-wait-timeout=<replaceable class="parameter">wait_time</replaceable></option></term>
+ <listitem>
+ <para>
+ Do not wait forever for table locks at the start of the dump. Instead
+ time out and abandon the dump if unable to lock a table within the
+ specified wait time. The wait time may be specified with the same
+ formats as accepted by <command>SET statement_timeout</>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term><option>--use-set-session-authorization</></term>
<listitem>
<para>
*** a/src/bin/pg_dump/pg_dump.c
--- b/src/bin/pg_dump/pg_dump.c
***************
*** 71,76 **** bool attrNames; /* put attr names into insert strings */
--- 71,77 ----
bool schemaOnly;
bool dataOnly;
bool aclsSkip;
+ const char *lockWaitTimeout;

/* subquery used to convert user ID (eg, datdba) to user name */
static const char *username_subquery;
***************
*** 265,270 **** main(int argc, char **argv)
--- 266,275 ----
{"disable-triggers", no_argument, &disable_triggers, 1},
{"no-tablespaces", no_argument, &outputNoTablespaces, 1},
{"use-set-session-authorization", no_argument, &use_setsessauth, 1},
+ /*
+ * long options with arguments and no short option letter
+ */
+ {"lock-wait-timeout", required_argument, NULL, 1},

{NULL, 0, NULL, 0}
};
***************
*** 278,283 **** main(int argc, char **argv)
--- 283,289 ----
strcpy(g_opaque_type, "opaque");

dataOnly = schemaOnly = dumpInserts = attrNames = false;
+ lockWaitTimeout = NULL;

progname = get_progname(argv[0]);

***************
*** 436,441 **** main(int argc, char **argv)
--- 442,452 ----
/* This covers the long options equivalent to -X xxx. */
break;

+ case 1:
+ /* lock-wait-timeout */
+ lockWaitTimeout = optarg;
+ break;
+
default:
fprintf(stderr, _("Try \"%s --help\" for more information.\n"), progname);
exit(1);
***************
*** 757,762 **** help(const char *progname)
--- 768,776 ----
printf(_(" -F, --format=c|t|p output file format (custom, tar, plain text)\n"));
printf(_(" -v, --verbose verbose mode\n"));
printf(_(" -Z, --compress=0-9 compression level for compressed formats\n"));
+ printf(_(" --lock-wait-timeout=WAIT_TIME\n"
+ " timeout and fail after waiting WAIT_TIME\n"
+ " for a table lock during startup\n"));
printf(_(" --help show this help, then exit\n"));
printf(_(" --version output version information, then exit\n"));

***************
*** 2956,2962 **** getTables(int *numTables)
int ntups;
int i;
PQExpBuffer query = createPQExpBuffer();
! PQExpBuffer delqry = createPQExpBuffer();
PQExpBuffer lockquery = createPQExpBuffer();
TableInfo *tblinfo;
int i_reltableoid;
--- 2970,2976 ----
int ntups;
int i;
PQExpBuffer query = createPQExpBuffer();
! PQExpBuffer waitquery = createPQExpBuffer();
PQExpBuffer lockquery = createPQExpBuffer();
TableInfo *tblinfo;
int i_reltableoid;
***************
*** 3191,3196 **** getTables(int *numTables)
--- 3205,3218 ----
i_reltablespace = PQfnumber(res, "reltablespace");
i_reloptions = PQfnumber(res, "reloptions");

+ if (lockWaitTimeout)
+ {
+ /* Abandon the dump instead of waiting forever for a table lock */
+ resetPQExpBuffer(waitquery);
+ appendPQExpBuffer(waitquery, "SET statement_timeout = ");
+ appendStringLiteralConn(waitquery, lockWaitTimeout, g_conn);
+ do_sql_command(g_conn, waitquery->data);
+ }
for (i = 0; i < ntups; i++)
{
tblinfo[i].dobj.objType = DO_TABLE;
***************
*** 3259,3264 **** getTables(int *numTables)
--- 3281,3290 ----
tblinfo[i].dobj.name);
}

+ if (lockWaitTimeout)
+ {
+ do_sql_command(g_conn, "SET statement_timeout = 0");
+ }
PQclear(res);

/*
***************
*** 3291,3297 **** getTables(int *numTables)
}

destroyPQExpBuffer(query);
! destroyPQExpBuffer(delqry);
destroyPQExpBuffer(lockquery);

return tblinfo;
--- 3317,3323 ----
}

destroyPQExpBuffer(query);
! destroyPQExpBuffer(waitquery);
destroyPQExpBuffer(lockquery);

return tblinfo;
Here is an updated version of this patch against head. It builds, runs and
functions as expected. I did not build the sgml.

I've made changes based on various comments as follows:

- use WAIT_TIME in description consistantly. Reworded for clarity.
(Stephan Frost)

- Use a separate query buffer in getTables() (Stephan Frost)

- sets statement_timeout=0 afterwards per new policy (Tom Lane, Marko Kreen)

- has only --long-option to conserve short option letters (Marko Kreen)

Regards

-dg

--
David Gould daveg@sonic.net 510 536 1443 510 282 0869
If simplicity worked, the world would be overrun with insects.

Re: [pgsql-es-ayuda] Forzar la escritura del log

On Wed, Jul 16, 2008 at 6:47 AM, Gorka <gorkapostgres@yahoo.es> wrote:
> Tengo postgres configurado de forma que me hace un log diario, … pero
> necesito ver ya el log de hoy, y creo que no me lo va a hacer hasta mañana.
>
>
>
> ¿Hay alguna manera de forzar la escritura del log para anticiparse a la
> programación o algo así?
>
>

mira log_rotation_age y log_rotation_size en el postgresql.conf

--
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

Re: [pgsql-es-ayuda] Reinstalacion

On Wed, Jul 16, 2008 at 4:30 PM, alejandrob <alejandrob@ospsip.org.ar> wrote:
> Amigos, estos dias tuve un problema con el servidor windows 2003, se me
> rompio el active directory, y al reparlo varios de los servicios dejaron de
> correr, entre ellos el postgres.
>
> Tenia Instalada la version 8.3, lo que hice, ya que no habia podido realizar
> backup en en los ultimos dias, fue copiar la carpeta a un temp, desintalar y
> volver a instalar en el mismo lugar, y luego pise la carpeta bin y data, y
> levanto el motor y veo todo y aproveche y le hice backup, ahora mi pregunta
> es la siguiente, esta bien esto que hice, puede traerme algun problema.
>

si es exactamente la misma version de postgres (y tiene que serlo
porque no habria subido la base de otra manera)... dberia andar bien..
quiza seria prudente levantar el backup que hiciste ahora (quiza en
otra maquina) para ver que no de ningun problema


--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda

Re: [pgsql-www] Spam filtering on the mailing lists

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Its sad how this is such an ongoing problem, but this is the first that I hear
that ppl are having problems ... looking at the message headers for a random
few, I notice that they are scoring >4, but just below 5:

X-Spam-Status: No, hits=4.855 tagged_above=0 required=5 tests=AWL=-1.994,
DCC_CHECK=1.37, DIGEST_MULTIPLE=0.001, HTML_MESSAGE=0.001,
MIME_HTML_ONLY=1.672, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=2.188,
RCVD_IN_SORBS_WEB=1.117
X-Spam-Level: ****

I can change the quarantining to be >4 if ppl want, which should greatly reduce
the # of messages going through ...

Thoughts?

- --On Wednesday, July 16, 2008 14:07:38 -0400 Andrew Sullivan
<ajs@commandprompt.com> wrote:

> On Wed, Jul 16, 2008 at 10:01:13AM -0700, Joshua D. Drake wrote:
>> I have just learned to overlook it.
>
> But moderators can't overlook it. We have to troll through piles of
> it. Much of it is in Cyrillic or CJK, and is just obviously not aimed
> at the list. We still have to process it.
>
> (I say "we" even though I am still unable to send mail from the
> account I moderate from, and therefore can't do any useful
> moderating.)
>
> A
>
> --
> Andrew Sullivan
> ajs@commandprompt.com
> +1 503 667 4564 x104
> http://www.commandprompt.com/
>
> --
> Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-www

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkh+q7IACgkQ4QvfyHIvDvPYfQCfchdCwNpL+90T5maoAWZUZttL
97wAoLMRAkqfszOxXojM7YNbUIZBX5ug
=9v1h
-----END PGP SIGNATURE-----


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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Josh was added as Admin a few weeks ago ... which you would know if you had
taken to actually check the entry :)


- --On Wednesday, July 16, 2008 21:31:10 -0400 Bruce Momjian <bruce@momjian.us>
wrote:

> Josh Berkus wrote:
>> Marc,
>>
>> So, can we also see about getting someone else authorized on Freshmeat? We
>> can take Neil off, if necessary; he's hardly more available than you. Good
>> other candidates are me, Robert, and Magnus.
>
> Marc, two people volunteered to also be admins on the PostgreSQL
> Freshmeat page, but I saw no reply from you and they are not listed:
>
> http://freshmeat.net/projects/pgsql/
>
> We need to have more than one admin for that, as Josh suggested.
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +

- --
Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org)
Email . scrappy@hub.org MSN . scrappy@hub.org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkh+qbgACgkQ4QvfyHIvDvO1UQCg2oMzv+3yXW3VXFzXLttk4FwF
CrsAoOjqF0SXHGdNyK0uoYEKsK9IJw8g
=CYQm
-----END PGP SIGNATURE-----


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

Re: [pdxpug] PDX PostgreSQL Meeting

>>>>> "Tim" == Tim Bruce <timsnews@tbruce.com> writes:

Tim> After talking (ahhm, e-mailing) with Selena, we won't be having our normal
Tim> meeting tomorow (Thursday, July 17th). The Sunday get-together (listed on
Tim> the pdxpug web site - http://pugs.postgresql.org/pdx) will replace it.

Tim> So don't go to Free Geek tomorrow looking for us!

Oh good. I was wondering. But I thought I could rehearse my talk. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

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

Re: [HACKERS] Change lock requirements for adding a trigger

Added to TODO:

* Reduce locking requirements for creating a trigger

http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php


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

Simon Riggs wrote:
>
> On Wed, 2008-06-04 at 16:33 -0400, Tom Lane wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> > > We have
> > > * relhasindex (bool) set by CREATE INDEX but not unset by DROP INDEX
> > > * relhasrules (bool)
> > > * reltriggers (int2) set by CREATE and DROP, since its an integer
> >
> > Right.
> >
> > > If CREATE INDEX can take a Share lock and can update pg_class, why would
> > > it not be theoretically possible for CREATE TRIGGER?
> >
> > It's (probably) theoretically possible, if we replace reltriggers with a
> > bool that acts more like relhasindex, ie it's a hint to go look in
> > pg_triggers.
>
> Looking at this area of locking, I've noticed that the locks held by
> CREATE TRIGGER are more of a problem than might be apparent.
>
> * Locks held by CREATE TRIGGER are an issue for trigger-based
> replication systems, where triggers are frequently added and removed to
> various tables.
>
> * ALTER TABLE .. ADD FOREIGN KEY holds an AccessExclusiveveLock on
> *both* referencing and referenced tables. It does this because we must
> add triggers to both tables. So reducing the lock strength required by
> CREATE TRIGGER would also allow a reduction in lock strength for adding
> FKs.
>
> So useful steps will be to
>
> * refactor pg_class code so that CREATE TRIGGER uses an identical
> approach to CREATE INDEX
>
> * reduce lock strength for CREATE TRIGGER and ALTER TABLE ... ADD
> FOREIGN KEY so that it takes a ShareLock during
> ATAddForeignKeyConstraint()
>
> * look at how we can reduce lock strength for other ALTER TABLE
> subcommands. Not sure how yet.
>
> --
> Simon Riggs www.2ndQuadrant.com
> PostgreSQL Training, Services and Support
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

--
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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[COMMITTERS] pgsql: Add to TODO: > > * Reduce locking requirements for creating a

Log Message:
-----------
Add to TODO:
>
> * Reduce locking requirements for creating a trigger
>
> http://archives.postgresql.org/pgsql-hackers/2008-06/msg00635.php
>

Modified Files:
--------------
pgsql/doc:
TODO (r1.2490 -> r1.2491)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/TODO?r1=1.2490&r2=1.2491)
pgsql/doc/src/FAQ:
TODO.html (r1.996 -> r1.997)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html?r1=1.996&r2=1.997)

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

Re: [pgsql-advocacy] PostgreSQL passes MySQL for Freshmeat Downloads

Josh Berkus wrote:
> Marc,
>
> So, can we also see about getting someone else authorized on Freshmeat? We
> can take Neil off, if necessary; he's hardly more available than you. Good
> other candidates are me, Robert, and Magnus.

Marc, two people volunteered to also be admins on the PostgreSQL
Freshmeat page, but I saw no reply from you and they are not listed:

http://freshmeat.net/projects/pgsql/

We need to have more than one admin for that, as Josh suggested.

--
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-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy

RE: [pgsql-es-ayuda] De informix a Postgresql

Pues como que en esas anda, CodeGear (Borland) lo vendiĂł a Embarcadero (http://www.embarcadero.com/) la versiĂłn 2007 del Delphi estĂĄ buena, pero ahora con ese movimiento quien sabe que pase… aunque no deja de ser una buena herramienta de desarrollo.

 

 

De: Francisco Javier Morosini Eguren [mailto:francisco.morosini@gmail.com]
Enviado el: miércoles, 16 de julio de 2008 07:00 p.m.
Para: César Piñera García
Asunto: Re: [pgsql-es-ayuda] De informix a Postgresql

 

Delphi? is not dead?

On Wed, Jul 16, 2008 at 6:16 PM, César Piñera García <cesar@gafi.com.mx> wrote:

Si necesitas mantener los sistemas en 4gl te recomiendo aubit 4gl (http://www.aubit.com/), tiene conexiĂłn nativa a Postgres, si vas a hacer de nuevo el sistema entonces mejor algo como Delphi Ăł C#.

 

Saludos,

 

Ing. César Piñera García.

 

De: Luis Fernando Lopez Aguilar [mailto:flopezg333@gmail.com]
Enviado el: miércoles, 16 de julio de 2008 08:31 a.m.
Para: pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] De informix a Postgresql

 

Help

Que lenguaje de programacion me recomiendan utilizar para reescribir 200000 lineas de codigo escrito en informix 4gl para usar postgresql como base de datos.

Saludos cordiales
Fernando Lopez

 

Re: [HACKERS] .psqlrc output for \pset commands

Index: src/bin/psql/startup.c
===================================================================
RCS file: /cvsroot/pgsql/src/bin/psql/startup.c,v
retrieving revision 1.149
diff -c -c -r1.149 startup.c
*** src/bin/psql/startup.c 1 Jul 2008 00:08:18 -0000 1.149
--- src/bin/psql/startup.c 17 Jul 2008 00:44:22 -0000
***************
*** 281,292 ****
*/
else
{
if (!options.no_psqlrc)
process_psqlrc(argv[0]);
!
! connection_warnings();
if (!pset.quiet && !pset.notty)
! printf(_("Type \"help\" for help.\n\n"));
if (!pset.notty)
initializeInput(options.no_readline ? 0 : 1);
if (options.action_string) /* -f - was used */
--- 281,294 ----
*/
else
{
+ connection_warnings();
+ if (!pset.quiet && !pset.notty)
+ printf(_("Type \"help\" for help.\n"));
if (!options.no_psqlrc)
process_psqlrc(argv[0]);
! /* output newline here because .psqlrc might output something */
if (!pset.quiet && !pset.notty)
! printf("\n");
if (!pset.notty)
initializeInput(options.no_readline ? 0 : 1);
if (options.action_string) /* -f - was used */
Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
>
> > In my .psqlrc I have:
> >
> > \pset format wrapped
> >
> > and this outputs this on psql startup:
> >
> > $ psql test
> > --> Output format is wrapped.
> > psql (8.4devel)
> > Type "help" for help.
> >
> > Is this desirable? \set QUIET at the top of .psqlrc fixes it, but I am
> > wondering if we should be automatically doing quiet while .psqlrc is
> > processed.
>
> I was wondering about this myself, but I'm still not used to the new banner.
> It seems kind of... curt. Perhaps it should just be a single line instead of
> two lines both around 20 characters...
>
> Anyways the thing that struck me as odd was the messages appearing *before*
> the header. It seems to me the header should print followed by .psqlrc output
> followed by normal output.

Do you like this better?

$ psql test
psql (8.4devel)
Type "help" for help.
Output format is wrapped.

test=>

The attached patch accomplishes this.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

[pdxpug] PDX PostgreSQL Meeting

After talking (ahhm, e-mailing) with Selena, we won't be having our normal
meeting tomorow (Thursday, July 17th). The Sunday get-together (listed on
the pdxpug web site - http://pugs.postgresql.org/pdx) will replace it.

So don't go to Free Geek tomorrow looking for us!

Tim
--
Timothy J. Bruce

Registered Linux User #325725


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

[COMMITTERS] aupg - aupg_src: I am so ashamed to commit this patch.

Log Message:
-----------
I am so ashamed to commit this patch. I created a BS function for PG < 8.3 to
prevent the (already hackish) txid code from failing to parse on a not-found function.

The longer-term solution is probably to eval the code based on version using
plpgsql and 'execute.'

Modified Files:
--------------
aupg_src/sql:
audit_infrastructure.sql (r1.18 -> r1.19)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/aupg/aupg_src/sql/audit_infrastructure.sql.diff?r1=1.18&r2=1.19)

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

Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline

On Wed, 16 Jul 2008, Sushant Sinha wrote:

> I will add test queries and their results for the corner cases in a
> separate file. I guess the only thing I am confused about is what should
> be the behavior of headline generation when Query items have words of
> size less than ShortWord. I guess the answer is to ignore ShortWord
> parameter but let me know if the answer is any different.
>

ShortWord is about headline text, it doesn't affects words in query,
so you can't discard them from query.

> -Sushant.
>
> On Thu, 2008-07-17 at 02:53 +0400, Oleg Bartunov wrote:
>> Sushant,
>>
>> first, please, provide simple test queries, which demonstrate the right work
>> in the corner cases. This will helps reviewers to test your patch and
>> helps you to make sure your new version is ok. For example:
>>
>> =# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery);
>> ts_headline
>> ------------------------------------------------------
>> <b>1</b> 2 <b>3</b> 4 5 <b>1</b> 2 <b>3</b> <b>1</b>
>>
>> This select breaks your code:
>>
>> =# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery,'maxfragments=2');
>> ts_headline
>> --------------
>> ... 2 ...
>>
>> and so on ....
>>
>>
>> Oleg
>> On Tue, 15 Jul 2008, Sushant Sinha wrote:
>>
>>> Attached a new patch that:
>>>
>>> 1. fixes previous bug
>>> 2. better handles the case when cover size is greater than the MaxWords.
>>> Basically it divides a cover greater than MaxWords into fragments of
>>> MaxWords, resizes each such fragment so that each end of the fragment
>>> contains a query word and then evaluates best fragments based on number of
>>> query words in each fragment. In case of tie it picks up the smaller
>>> fragment. This allows more query words to be shown with multiple fragments
>>> in case a single cover is larger than the MaxWords.
>>>
>>> The resizing of a fragment such that each end is a query word provides room
>>> for stretching both sides of the fragment. This (hopefully) better presents
>>> the context in which query words appear in the document. If a cover is
>>> smaller than MaxWords then the cover is treated as a fragment.
>>>
>>> Let me know if you have any more suggestions or anything is not clear.
>>>
>>> I have not yet added the regression tests. The regression test suite seemed
>>> to be only ensuring that the function works. How many tests should I be
>>> adding? Is there any other place that I need to add different test cases for
>>> the function?
>>>
>>> -Sushant.
>>>
>>>
>>> Nice. But it will be good to resolve following issues:
>>>> 1) Patch contains mistakes, I didn't investigate or carefully read it. Get
>>>> http://www.sai.msu.su/~megera/postgres/fts/apod.dump.gz<http://www.sai.msu.su/%7Emegera/postgres/fts/apod.dump.gz>and load in db.
>>>>
>>>> Queries
>>>> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
>>>> from apod where to_tsvector(body) @@ plainto_tsquery('black hole');
>>>>
>>>> and
>>>>
>>>> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
>>>> from apod;
>>>>
>>>> crash postgresql :(
>>>>
>>>> 2) pls, include in your patch documentation and regression tests.
>>>>
>>>>
>>>>> Another change that I was thinking:
>>>>>
>>>>> Right now if cover size > max_words then I just cut the trailing words.
>>>>> Instead I was thinking that we should split the cover into more
>>>>> fragments such that each fragment contains a few query words. Then each
>>>>> fragment will not contain all query words but will show more occurrences
>>>>> of query words in the headline. I would like to know what your opinion
>>>>> on this is.
>>>>>
>>>>
>>>> Agreed.
>>>>
>>>>
>>>> --
>>>> Teodor Sigaev E-mail: teodor@sigaev.ru
>>>> WWW:
>>>> http://www.sigaev.ru/
>>>>
>>>
>>
>> Regards,
>> Oleg
>> _____________________________________________________________
>> Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
>> Sternberg Astronomical Institute, Moscow University, Russia
>> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
>> phone: +007(495)939-16-83, +007(495)939-23-83
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

--
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] De informix a Postgresql

Si necesitas mantener los sistemas en 4gl te recomiendo aubit 4gl (http://www.aubit.com/), tiene conexiĂłn nativa a Postgres, si vas a hacer de nuevo el sistema entonces mejor algo como Delphi Ăł C#.

 

Saludos,

 

Ing. César Piñera García.

 

De: Luis Fernando Lopez Aguilar [mailto:flopezg333@gmail.com]
Enviado el: miércoles, 16 de julio de 2008 08:31 a.m.
Para: pgsql-es-ayuda@postgresql.org
Asunto: [pgsql-es-ayuda] De informix a Postgresql

 

Help

Que lenguaje de programacion me recomiendan utilizar para reescribir 200000 lineas de codigo escrito en informix 4gl para usar postgresql como base de datos.

Saludos cordiales
Fernando Lopez

Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline

I will add test queries and their results for the corner cases in a
separate file. I guess the only thing I am confused about is what should
be the behavior of headline generation when Query items have words of
size less than ShortWord. I guess the answer is to ignore ShortWord
parameter but let me know if the answer is any different.

-Sushant.

On Thu, 2008-07-17 at 02:53 +0400, Oleg Bartunov wrote:
> Sushant,
>
> first, please, provide simple test queries, which demonstrate the right work
> in the corner cases. This will helps reviewers to test your patch and
> helps you to make sure your new version is ok. For example:
>
> =# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery);
> ts_headline
> ------------------------------------------------------
> <b>1</b> 2 <b>3</b> 4 5 <b>1</b> 2 <b>3</b> <b>1</b>
>
> This select breaks your code:
>
> =# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery,'maxfragments=2');
> ts_headline
> --------------
> ... 2 ...
>
> and so on ....
>
>
> Oleg
> On Tue, 15 Jul 2008, Sushant Sinha wrote:
>
> > Attached a new patch that:
> >
> > 1. fixes previous bug
> > 2. better handles the case when cover size is greater than the MaxWords.
> > Basically it divides a cover greater than MaxWords into fragments of
> > MaxWords, resizes each such fragment so that each end of the fragment
> > contains a query word and then evaluates best fragments based on number of
> > query words in each fragment. In case of tie it picks up the smaller
> > fragment. This allows more query words to be shown with multiple fragments
> > in case a single cover is larger than the MaxWords.
> >
> > The resizing of a fragment such that each end is a query word provides room
> > for stretching both sides of the fragment. This (hopefully) better presents
> > the context in which query words appear in the document. If a cover is
> > smaller than MaxWords then the cover is treated as a fragment.
> >
> > Let me know if you have any more suggestions or anything is not clear.
> >
> > I have not yet added the regression tests. The regression test suite seemed
> > to be only ensuring that the function works. How many tests should I be
> > adding? Is there any other place that I need to add different test cases for
> > the function?
> >
> > -Sushant.
> >
> >
> > Nice. But it will be good to resolve following issues:
> >> 1) Patch contains mistakes, I didn't investigate or carefully read it. Get
> >> http://www.sai.msu.su/~megera/postgres/fts/apod.dump.gz<http://www.sai.msu.su/%7Emegera/postgres/fts/apod.dump.gz>and load in db.
> >>
> >> Queries
> >> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
> >> from apod where to_tsvector(body) @@ plainto_tsquery('black hole');
> >>
> >> and
> >>
> >> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
> >> from apod;
> >>
> >> crash postgresql :(
> >>
> >> 2) pls, include in your patch documentation and regression tests.
> >>
> >>
> >>> Another change that I was thinking:
> >>>
> >>> Right now if cover size > max_words then I just cut the trailing words.
> >>> Instead I was thinking that we should split the cover into more
> >>> fragments such that each fragment contains a few query words. Then each
> >>> fragment will not contain all query words but will show more occurrences
> >>> of query words in the headline. I would like to know what your opinion
> >>> on this is.
> >>>
> >>
> >> Agreed.
> >>
> >>
> >> --
> >> Teodor Sigaev E-mail: teodor@sigaev.ru
> >> WWW:
> >> http://www.sigaev.ru/
> >>
> >
>
> Regards,
> Oleg
> _____________________________________________________________
> Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
> Sternberg Astronomical Institute, Moscow University, Russia
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(495)939-16-83, +007(495)939-23-83


--
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: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

On Wed, 2008-07-16 at 17:59 -0400, Neil Conway wrote:
> On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> > TRUNCATE foo;
> > TRUNCATE foo;
> >
> > works well.
> >
> > So why do we need
> >
> > TRUNCATE foo, foo;
>
> For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
> rather inconsistent.

Inconsistent with what exactly?

If a proposal to support this was made on hackers, it would be laughed
away. It is not required for functionality, usability, standards
compliance, backwards compatibility, robustness, performance, internal
coding simplicity, portability, marketing or external compatibility. For
what reason would we do it? Nobody has said.

And as I pointed out, other commands fail in similar circumstances.

Consistency is required, but consistency in making balanced judgements
about feature additions.

Our users will be surprised to find this was at the top of our list
ahead of other patches during a commit fest, other agreed TODO items and
other proposals from users.

--
Simon Riggs

www.2ndQuadrant.com

PostgreSQL Training, Services and Support


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

Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline

Sushant,

first, please, provide simple test queries, which demonstrate the right work
in the corner cases. This will helps reviewers to test your patch and
helps you to make sure your new version is ok. For example:

=# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery);
ts_headline
------------------------------------------------------
<b>1</b> 2 <b>3</b> 4 5 <b>1</b> 2 <b>3</b> <b>1</b>

This select breaks your code:

=# select ts_headline('1 2 3 4 5 1 2 3 1','1&3'::tsquery,'maxfragments=2');
ts_headline
--------------
... 2 ...

and so on ....


Oleg
On Tue, 15 Jul 2008, Sushant Sinha wrote:

> Attached a new patch that:
>
> 1. fixes previous bug
> 2. better handles the case when cover size is greater than the MaxWords.
> Basically it divides a cover greater than MaxWords into fragments of
> MaxWords, resizes each such fragment so that each end of the fragment
> contains a query word and then evaluates best fragments based on number of
> query words in each fragment. In case of tie it picks up the smaller
> fragment. This allows more query words to be shown with multiple fragments
> in case a single cover is larger than the MaxWords.
>
> The resizing of a fragment such that each end is a query word provides room
> for stretching both sides of the fragment. This (hopefully) better presents
> the context in which query words appear in the document. If a cover is
> smaller than MaxWords then the cover is treated as a fragment.
>
> Let me know if you have any more suggestions or anything is not clear.
>
> I have not yet added the regression tests. The regression test suite seemed
> to be only ensuring that the function works. How many tests should I be
> adding? Is there any other place that I need to add different test cases for
> the function?
>
> -Sushant.
>
>
> Nice. But it will be good to resolve following issues:
>> 1) Patch contains mistakes, I didn't investigate or carefully read it. Get
>> http://www.sai.msu.su/~megera/postgres/fts/apod.dump.gzand load in db.
>>
>> Queries
>> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
>> from apod where to_tsvector(body) @@ plainto_tsquery('black hole');
>>
>> and
>>
>> # select ts_headline(body, plainto_tsquery('black hole'), 'MaxFragments=1')
>> from apod;
>>
>> crash postgresql :(
>>
>> 2) pls, include in your patch documentation and regression tests.
>>
>>
>>> Another change that I was thinking:
>>>
>>> Right now if cover size > max_words then I just cut the trailing words.
>>> Instead I was thinking that we should split the cover into more
>>> fragments such that each fragment contains a few query words. Then each
>>> fragment will not contain all query words but will show more occurrences
>>> of query words in the headline. I would like to know what your opinion
>>> on this is.
>>>
>>
>> Agreed.
>>
>>
>> --
>> Teodor Sigaev E-mail: teodor@sigaev.ru
>> WWW:
>> http://www.sigaev.ru/
>>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83

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

Re: [BUGS] Psql or test application hangs when interface is down for the DB server

Thanks Gregory,

You right, of course, about that. It is 4 minutes I wasn't paying attention and thought that I have found something odd. The last packet is sent a minute and a half after the first and I miss-read that for 20 seconds.

Cheers,

Val

--- On Wed, 16/7/08, Gregory Stark <stark@enterprisedb.com> wrote:

> From: Gregory Stark <stark@enterprisedb.com>
> Subject: Re: [BUGS] Psql or test application hangs when interface is down for the DB server
> To: valiouk@yahoo.co.uk
> Cc: "ext Tom Lane" <tgl@sss.pgh.pa.us>, "K, Niranjan (NSN - IN/Bangalore)" <niranjan.k@nsn.com>, pgsql-bugs@postgresql.org
> Date: Wednesday, 16 July, 2008, 6:33 PM
> "Valentin Bogdanov" <valiouk@yahoo.co.uk>
> writes:
>
> > I have noticed this as well. Blocks in poll(), timeout
> parameter -1,
>
> Oh good point. non-blocking sockets and poll/select let you
> control the
> timeout too.
>
> > meaning infinite then after 4 minutes on my system
> poll() returns 1 and
> > getsockopt() is called with SO_ERROR. SYN packets are
> tried only for the
> > default tcp timeout of 20 seconds.
>
> Uhm, 20 seconds would be an unreasonably low default. I
> think the RFCs mandate
> timeouts closer to the 4 minutes you describe.
>
> --
> Gregory Stark
> EnterpriseDB

http://www.enterprisedb.com
> Ask me about EnterpriseDB's RemoteDBA services!
>
> --
> Sent via pgsql-bugs mailing list
> (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs


__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

--
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] Psql or test application hangs when interface is down for the DB server

Thanks Gregory,

You right, of course, about that. It is 4 minutes I wasn't paying attention and thought that I have found something odd. The last packet is sent a minute and a half after the first and I miss-read that for 20 seconds.

Cheers,

Val

--- On Wed, 16/7/08, Gregory Stark <stark@enterprisedb.com> wrote:

> From: Gregory Stark <stark@enterprisedb.com>
> Subject: Re: [BUGS] Psql or test application hangs when interface is down for the DB server
> To: valiouk@yahoo.co.uk
> Cc: "ext Tom Lane" <tgl@sss.pgh.pa.us>, "K, Niranjan (NSN - IN/Bangalore)" <niranjan.k@nsn.com>, pgsql-bugs@postgresql.org
> Date: Wednesday, 16 July, 2008, 6:33 PM
> "Valentin Bogdanov" <valiouk@yahoo.co.uk>
> writes:
>
> > I have noticed this as well. Blocks in poll(), timeout
> parameter -1,
>
> Oh good point. non-blocking sockets and poll/select let you
> control the
> timeout too.
>
> > meaning infinite then after 4 minutes on my system
> poll() returns 1 and
> > getsockopt() is called with SO_ERROR. SYN packets are
> tried only for the
> > default tcp timeout of 20 seconds.
>
> Uhm, 20 seconds would be an unreasonably low default. I
> think the RFCs mandate
> timeouts closer to the 4 minutes you describe.
>
> --
> Gregory Stark
> EnterpriseDB

http://www.enterprisedb.com
> Ask me about EnterpriseDB's RemoteDBA services!
>
> --
> Sent via pgsql-bugs mailing list
> (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs


__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

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

Re: [pgsql-students] EC2 with Postgresql

On Wednesday 16 July 2008 16:47:01 Kunal Gupta wrote:
> Hi Guys,
>
> I have following challenges:
>
> - I am suppose to connect to amazon EC2 and get the various information.
>
> - For this I am suppose to create a function in plpythonu.
>
> - Problem: in create function if we write "import" statement then we can
> refer to standard libraries, but here I have to import a class made by me.
>
> can anyone tell if I can write " import X " where X is a class code by me
> and where to place this X class ---- this is while if am creating a
> function in postgresql using plpythonu.
>

This shouldn't be any different than including your custom class in a normal
python script, you just have to make sure postgres knows where to find the
file and that it has read permissions on it. HTH.

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

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

Re: [pgsql-www] Spam filtering on the mailing lists

On Wed, 2008-07-16 at 14:07 -0400, Andrew Sullivan wrote:
> On Wed, Jul 16, 2008 at 10:01:13AM -0700, Joshua D. Drake wrote:
> > I have just learned to overlook it.
>
> But moderators can't overlook it. We have to troll through piles of
> it. Much of it is in Cyrillic or CJK, and is just obviously not aimed
> at the list. We still have to process it.

Yeah I thought about it afterword, I moderate announce. I get maybe a
dozen a day.


Joshua D. Drake


--
The PostgreSQL Company since 1997: http://www.commandprompt.com/

PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate


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

Re: [GENERAL] 8.3.3 regression test on SCO 5.0.7

> "Harvey, Allan AC" <HarveyA@OneSteel.com> writes:
> >> "Harvey, Allan AC" <HarveyA@OneSteel.com> writes:
> >>> creating template1 database in
> /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_che
> ck/data/base/1 ... =: is not an identifier
>
> > A diff of postgres.bki on the SCO system to another that
> completed the regression
> > tests OK produced no differences.
>
> Huh ... so much for the easy theory. What you need to do
> next is figure
> out exactly where the failure is coming from. Try running initdb with
> --debug option (this will produce LOTS of stuff on stderr),
> and post the
> last hundred or so lines of debug output.

I don't think this is what you were expecting, I know I was not, but then I don't know much.

Allan

DEBUG: StartTransaction
DEBUG: name: unnamed; blockState: DEFAULT; state: INPROGR, xid/subid/cid: 0/1/0, nestlvl: 1, children:
DEBUG: start transaction
DEBUG: CommitTransaction
DEBUG: name: unnamed; blockState: STARTED; state: INPROGR, xid/subid/cid: 0/1/35, nestlvl: 1, children:
DEBUG: commit transaction
DEBUG: proc_exit(0)
DEBUG: shmem_exit(0)
DEBUG: exit(0)
ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the -A option the
next time you run initdb.

Success. You can now start the database server using:

/upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/postgres -D /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/data
or
/upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/install//usr/local/pgsql/bin/pg_ctl -D /upgrades/postgres/postgresql-8.3.3/src/test/regress/./tmp_check/data -l logfile start


The material contained in this email may be confidential, privileged or copyrighted. If you are not the intended recipient, use, disclosure or copying of this information is prohibited. If you have received this document in error, please advise the sender and delete the document. Neither OneSteel nor the sender accept responsibility for any viruses contained in this email or any attachments.

--
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] Crear un evento cada vez que se hace una UPDATE

2008/7/16 Alvaro Uría <fermat@rigel.deusto.es>:
> Hola,
>
> El 16/07/08 17:26, Jaime Casanova escribió:
>> On 7/16/08, Alvaro Uría <fermat@rigel.deusto.es> wrote:
>>> En Postgres, la he creado tal que,
>>>
>>> validNotBefore timestamp NOT NULL default '0000-00-00 00:00:00',
>>> validNotAfter timestamp NOT NULL default '0000-00-00 00:00:00',
>>
>> te dejo hacer eso? esa fecha no es valida en postgres...
>
> He copiado del fichero original donde lo escribí, y después de mandarlo
> me he acordado de que hubo cosas que tuve que modificar.
>
> En lugar de esa fecha, puse una en el pasado (1970-blablabal :-)
>

eso me lo creo mas...


>
> Con ánimo de aprender, ¿por qué no se podría hacer con una "CREATE RULE"?
>

de poder puedes, pero las reglas (RULE) en realidad son como macros
que se expanden en linea (o al menos es una forma de explicarlo) y eso
hace que puedan surgir problemas si una regla que se expande te agrega
dos llamadas a la misma funcion volatil (randim(), nextval(), etc)
cuando tu solo esperabas una...

> Por otro lado, ¿cómo haríais el trigger? (entendería un STFW o RTFM,
> pero bastante de eso ya lo he hecho y necesito una guía para "la primera
> vez")
>
> ¿El trigger sería algo así? (generalmente, la update es a un solo
> registro, por lo que el "for each" supongo que se ejecutaría una sola vez)
>
> CREATE TRIGGER tresource_update AFTER UPDATE ON TResource
> FOR EACH ROW EXECUTE PROCEDURE update_stamp(uploaded);
>

BEFORE UPDATE si lo haces AFTER ya habras grabado el registro y ya
nada puedes hacer sino actualizarlo con UPDATE...

quedaria asi:
CREATE TRIGGER tresource_update BEFORE UPDATE ON TResource
FOR EACH ROW EXECUTE PROCEDURE update_stamp();

> ¿Y el procedure?
>
> CREATE OR REPLACE FUNCTION update_stamp() returns trigger as $$
> begin
> return now();
> end;
> $$ language plpgsql;
>
>

CREATE OR REPLACE FUNCTION update_stamp() returns trigger as $$
begin
NEW.uploaded = current_timestamp;

return NEW;
end;
$$ language plpgsql;


> Saludos, y gracias.
> Alvaro Uría
>
>

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Guayaquil - Ecuador
Cel. (593) 87171157
--
TIP 9: visita nuestro canal de IRC #postgresql-es en irc.freenode.net

Re: [PERFORM] Difference between 8.1 & 8.3

Patrick Vachon wrote:

> Hi guys,
>
> I've got a query that is running slower on 8.3 than on 8.1 (with
> equivalent server config),
> because the join ordering is not the same, at least that's my guess... ;-)
>
> In 8.1.4, table A had 122880 pages, B 112690 pages and C 80600 pages.
> Now in 8.3.3, table A has only 77560 pages, B 69580 but C remains at
> 80600 pages.
>
> In 8.1 the tables were joined in that way (using explain analyse):
> C join A join B
> now in 8.3:
> B join A join C
> Beside that, the plan is very similar, but the indexes used are not the
> same.
>
> Could the number of disk pages of a table influence the
> order in which it is joined, even when it is scanned with an index?
>
> I'm pretty sure it is because of the reduced table sizes,
> since the server configuration is the same.
>
> Thoughts?

8.3 has fewer automatic casts to text types; perhaps you have indexes which are not being used because of mismatched types ? Perhaps an EXPLAIN ANALYZE from both, if possible, would clairfy.

HTH,

Greg Williamson
Senior DBA
DigitalGlobe

Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information and must be protected in accordance with those provisions. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

(My corporate masters made me say this.)

Re: [COMMITTERS] pgsql: Allow TRUNCATE foo, foo to succeed, per report from Nikhils.

On Wed, 2008-07-16 at 21:39 +0100, Simon Riggs wrote:
> TRUNCATE foo;
> TRUNCATE foo;
>
> works well.
>
> So why do we need
>
> TRUNCATE foo, foo;

For the sake of completeness? Having "TRUNCATE foo, foo" fail would be
rather inconsistent.

-Neil

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

[PERFORM] Difference between 8.1 & 8.3

Hi guys,

I've got a query that is running slower on 8.3 than on 8.1 (with equivalent server config),
because the join ordering is not the same, at least that's my guess... ;-)

In 8.1.4, table A had 122880 pages, B 112690 pages and C 80600 pages.
Now in 8.3.3, table A has only 77560 pages, B 69580 but C remains at 80600 pages.

In 8.1 the tables were joined in that way (using explain analyse):
C join A join B
now in 8.3:
B join A join C
Beside that, the plan is very similar, but the indexes used are not the same.

Could the number of disk pages of a table influence the
order in which it is joined, even when it is scanned with an index?

I'm pretty sure it is because of the reduced table sizes,
since the server configuration is the same.

Thoughts?

Thanks,
Patrick

[pgsql-es-ayuda] Reinstalacion

Amigos, estos dias tuve un problema con el servidor windows 2003, se me
rompio el active directory, y al reparlo varios de los servicios dejaron de
correr, entre ellos el postgres.

Tenia Instalada la version 8.3, lo que hice, ya que no habia podido realizar
backup en en los ultimos dias, fue copiar la carpeta a un temp, desintalar y
volver a instalar en el mismo lugar, y luego pise la carpeta bin y data, y
levanto el motor y veo todo y aproveche y le hice backup, ahora mi pregunta
es la siguiente, esta bien esto que hice, puede traerme algun problema.

Bueno muchas gracias

Saludos

Alejandro..

--
TIP 3: Si encontraste la respuesta a tu problema, publícala, otros te lo agradecerán

[pgsql-es-ayuda] De informix a Postgresql

Help

Que lenguaje de programacion me recomiendan utilizar para reescribir 200000 lineas de codigo escrito en informix 4gl para usar postgresql como base de datos.

Saludos cordiales
Fernando Lopez