At 02:22 PM 11/11/2005 +0100, Martijn van Oosterhout wrote:
But once you've prepared a transaction, you can't reopen it, all you
can do is either commit it or abort it. I don't see how prepared
transaction relate to webapps at all.
See also the docs:
http://www.postgresql.org/docs/8.1/static/sq
Have you looked at PL/R?
http://www.varlena.com/varlena/GeneralBits/Tidbits/bernier/art_66/
graphingWithR.html
On Nov 11, 2005, at 2:09 PM, Hrishikesh Deshmukh wrote:
Dear All,
Sincere apologies if this is a re-post.
Is there a good reporting tool which will let me generate scatter
plots/
Hugo <[EMAIL PROTECTED]> writes:
> ERROR: could not open file "c:file.csv" for reading: No such file or
> directory
> CONTEXT: SQL statement "copy comisiones.avon(
> zona,ano,campana,fechapro,contrato,situacion,documento,tipo,subtipo,exentas=
> ,gravadas,iva,importe
> ) from 'c:\file.csv' with CSV"
"Prasad Duggineni" <[EMAIL PROTECTED]> writes:
> I am getting the compile error in the =
> /usr/include/pgsql/server/catalog/pg_attribute.h after installing the =
> postgres8.1.
> /usr/include/pgsql/server/catalog/pg_attribute.h:44:26: macro "CATALOG" =
> passed 2 arguments, but takes just 1
CATA
Dear All,
Sincere apologies if this is a re-post.
Is there a good reporting tool which will let me generate scatter plots/ histograms say for a query like
select col1, col2, col3,.col51
from table idsvsgenes
where pid=1000_art;
I have lots of data in a table and generating scatterplots/ hi
Hi,
calling a function with select esquema.fn_importa_csv('c:\file.csv')
I get this errror:
ERROR: could not open file "c:file.csv" for reading: No such file or directory
CONTEXT: SQL statement "copy comisiones.avon(
zona,ano,campana,fechapro,contrato,situacion,documento,tipo,subtipo,exentas,gra
I am getting the compile error in the
/usr/include/pgsql/server/catalog/pg_attribute.h after installing the
postgres8.1. I never had this problem for the postgres8.03 . please advice
me to fix this problem.
/usr/include/pgsql/server/catalog/pg_attribute.h:44:26: macro "CATALOG"
passed 2
Johnny Ljunggren wrote:
1. Replication - multimaster
I'll try to explain the setup to the best of my ability:
Three centers:
Main center - database with a backup database
Center 1 - database with a backup database
Center 2 - database with a backup database (same as center 1)
Application on the t
"Andrus" <[EMAIL PROTECTED]> writes:
>> (Hint: all the other ones use dictionary
>> sorting rules, which have at least a discrimination against spaces.)
> show lc_collate; -- returns "Estonian_Estonia.1257"
> ...
> I don't see any space discrimination on sorting here.
Hmm ... I should probably ha
"Carlos Oliva" <[EMAIL PROTECTED]> writes:
> Would rebooting the server interfere with the work of pg_autovacuum? I
> imagine that pg_autovacuum would loose the information that it gathered
> prior to the reboot.
The only long-term state used by autovacuum is the contents of the
statistics views,
> (Hint: all the other ones use dictionary
> sorting rules, which have at least a discrimination against spaces.)
Tom,
thank you. I ran the following code in 8.1
show lc_collate; -- returns "Estonian_Estonia.1257"
create temp table foo ( bar char(10) ) on commit drop ;
insert into foo values ('A
Hello everyone!
I've been assigned the task of choosing the database soloution for our
next project and have two questions I need to figure out:
1. Replication - multimaster
I'll try to explain the setup to the best of my ability:
Three centers:
Main center - database with a backup database
C
Uwe
In attempting to understand the underlying intent of the statement, I have a
question.
What purpose does the statement "myrow" serve in this expression.
Bob
- Original Message -
From: "Uwe C. Schroeder" <[EMAIL PROTECTED]>
To: "Bob Pawley" <[EMAIL PROTECTED]>
Cc:
Sent: Thursda
Hi Matthew,
Would rebooting the server interfere with the work of pg_autovacuum? I
imagine that pg_autovacuum would loose the information that it gathered
prior to the reboot.
Would not pg_autovacuum need to gather data about the database again before
it can judge if it should analyze/vacuum a ta
"Andrus" <[EMAIL PROTECTED]> writes:
> Maybe there is some setting which I can use to inform Postgres that sorting
> order is strictly by single byte, not affected by byte sequences.
AFAIK, C/POSIX is the *only* commonly used locale in which that holds.
Do you have a counterexample? (Hint: all t
>> I expected that making planner to use primary key index in case of
>>
>> WHERE bar::CHAR(3)='ABC'
>> WHERE bar BETWEEN 'ABC' AND 'ABC' || CHR(255)
>> WHERE SUBSTRING( bar FOR 3 )='ABC'
>
> Which doesn't necessarily work because of how some collations may work.
> The first 3 characters of the str
On Fri, Nov 11, 2005 at 11:58:22 -0500,
Dennis Veatch <[EMAIL PROTECTED]> wrote:
>
> Yeah I saw that list there but 2 quarters couldn't buy me a clue as to which
> was most suitable for me.
Your other option is to read two books. One about Postgres and one about
relational databases. The onli
Thanks for the response.
does the global directory exist on the drive you are syncing from? If
so ...
then it's a problem with your rsync.
check the options you are using with the rsync command.
check the rsync configurations in /etc/rsyncd.conf on the drive.
what user are you running the rsy
On Fri, 2005-11-11 at 11:36 -0500, Robert Treat wrote:
> On Thursday 10 November 2005 21:03, Dennis Veatch wrote:
> > I guess to much information can be an overload. Been surfin' to find a
> > decent book and don't really know which one to try. I have a um, not
> > exactly vague understanding of a
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
> I'm running postgresql 8.0.2 on Linux.
> When I do
> select * from datagraph."MyTable" where "KC" like "TTT%"
> , postgres responds with "ERROR: unsupported type: 17296".
If KC is a domain type, you need to update to 8.0.4.
2005-06-01 13:05 tgl
On Friday 11 November 2005 12:01, Michael Schmidt wrote:
> The Sams book (Douglas & Douglas, PostgreSQL: The comprehensive guide to
> building, programming, and administering PostgreSQL databases, 2nd ed) is
> very good. I wrote a little comment about it earlier in this group. My
> only complaint
Thanks for the quick response. We do both pg_dump and file system
backups, and I agree that pg_dump is the way to go. I thought I'd
practice restoring from a filesystem backup though since I've never
done that before.
Thank you.
On Nov 10, 2005, at 6:07 PM, Scott Frankel wrote:
I'm no expe
The Sams book (Douglas & Douglas, PostgreSQL: The comprehensive guide
to building, programming, and administering PostgreSQL databases, 2nd ed) is
very good. I wrote a little comment about it earlier in this group.
My only complaint is that there isn't any information on rules. For basic
>
> Bill Bartlett wrote:
>
> >I hit this exact same problem, and my initial reaction was
> the same as
> >yours -- psql was "hanging". After much head-banging, I discovered
> >that it is not in fact hanging, but is instead getting confused by
> >being run from inside Putty, Cygwin, xterm,
On Friday 11 November 2005 11:36, Robert Treat wrote:
Big snip.
>
> I think I would recommend "Beginning Databases with PostgreSQL, 2nd
> Edition" from Apress, as it's aimed toward beginers. (full disclosure, I
> did the technical review for the book, though I get no money if you buy it)
>
> Otherw
Robert Treat <[EMAIL PROTECTED]> schrieb:
> > Anyway I am open to some good recommendations.
>
> I think I would recommend "Beginning Databases with PostgreSQL, 2nd Edition"
> from Apress, as it's aimed toward beginers. (full disclosure, I did the
> technical review for the book, though I get no
OK, I've found it:
http://www.postgresql.org/docs/8.1/interactive/catalog-pg-autovacuum.html
One more incentive to upgrade as quickly as possible.
Cheers,
Csaba.
On Fri, 2005-11-11 at 17:40, Csaba Nagy wrote:
> [snip]
> > With the release of 8.1 and it's integrated version of autovacuum, you
>
[snip]
> With the release of 8.1 and it's integrated version of autovacuum, you
> can now set per table settings for for vauum and analyze thresholds,
> vacuum cost delay, and table enable / disable. This addresses what was
> probably the largest deficiency with the old contrib version.
Cool !
On Thursday 10 November 2005 21:03, Dennis Veatch wrote:
> I guess to much information can be an overload. Been surfin' to find a
> decent book and don't really know which one to try. I have a um, not
> exactly vague understanding of a database.
>
> Meaning I can create the tables and crude/element
This is also true in my situation, where I have some medium sized
tables, which have a always just a handful of rows heavily updated. The
amount of updates is not too big related to the size of the table, but
the repeated update of the same row will cause problems before
autovacuum will kick in, as
Vivek Khera wrote:
Another issue with autovacuum (haven't investigated the 8.1 version
yet) is that you can't make different threshhold settings for
different tables. For example, I have some tables that are a handful
of rows but are updated bazillions of times per day, and other tables
with
On Nov 10, 2005, at 3:43 PM, Matthew T. O'Connor wrote:
Yes exactly, and if you find that pg_autovacuum is never or not
often enough firing off vacuum comands, then you will need to play
with the threshold settings. The default thresholds for
pg_autovacuum are too conservative for most pe
Hi
I'm running postgresql 8.0.2 on Linux.
In one of our databases we have a table (lets call it
datagraph."MyTable", the real name is german), that
includes a field (called "KC") of type datagraph."Char".
datagraph."Char" is a subtype of varchar, created with
create domain datagraph."Char" as
On 11/11/05, Andrus <[EMAIL PROTECTED]> wrote:
> >> SELECT * FROM foo WHERE bar::CHAR(3)='ABC';
>
> > Your query is the same as using LIKE, so why not express it that way?
>
> I want simply to select by first 3 characters. LIKE is too powerful and
> unnessecary. LIKE requires
> escaping % and ? cha
On Fri, 11 Nov 2005, Andrus wrote:
> >> SELECT * FROM foo WHERE bar::CHAR(3)='ABC';
>
> > Your query is the same as using LIKE, so why not express it that way?
>
> I want simply to select by first 3 characters. LIKE is too powerful and
> unnessecary. LIKE requires
> escaping % and ? characters in
Hi Richard,
While in the process of responding to your email I found out what was
doing it. It was the grouping of the team_players team_id instead of
the team team_id.
Here's some table numbers:
team => 31720 rows,
team_players => 464896 rows,
player => 948 rows
player_updates => 5414 row
Jeff Davis <[EMAIL PROTECTED]> writes:
> From the docs on plperl:
> "Usually you'll want to return rows one at a time, both to speed up
> startup time and to keep from queueing up the entire result set in
> memory. You can do this with return_next as illustrated below."
> Am I misunderstanding the
hi,
search for Slony I or pgreplicator ...
you can search for it in pgfoundry or try typing the names in google,
I have tested with pgreplicator and it works great for multimaster replication ...
vishOn 11/10/05, Víctor Narváez <[EMAIL PROTECTED]> wrote:
Hi, my name is Victor, and I´m a student
"Andrus" <[EMAIL PROTECTED]> writes:
> Planner must use index
> CREATE TABLE foo ( bar CHAR(10) PRIMARY KEY );
> for queries like
> SELECT * FROM foo WHERE bar::CHAR(3)='ABC';
> Can you make this patch or add this to todo list ?
This isn't going to happen for exactly the same reason that LIKE
opt
Martijn van Oosterhout writes:
> On Fri, Nov 11, 2005 at 05:45:28PM +0800, Lincoln Yeoh wrote:
>> Assuming the transactions don't explicitly do any locks ...
> Every transaction takes locks, on every table it accesses. Shared lock,
> but locks anyway. UPDATEs take stronger locks, so any UPDATE ma
Hi, my name is Victor, and I´m a student in Mexico.
I have to do a school proyect with a DBM, and we
chosed postgres.
I´m looking for a postgres replicator that work´s
with
windows and mac, could you tell me where to find it?
thank you in advance.
P.S. by the way, do you happend to kno
Is there a faster way to make a copy of a table than to do this? :
select * into mytable_copy from mytable;
Thanks,
Orhan
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if
On Fri, Nov 11, 2005 at 02:22:05PM +0100, Martijn van Oosterhout wrote:
> Every transaction takes locks, on every table it accesses. Shared lock,
> but locks anyway. UPDATEs take stronger locks, so any UPDATE may cause
> other queries to wait until you COMMIT or ABORT.
Note also, you don't want to
On Fri, Nov 11, 2005 at 05:45:28PM +0800, Lincoln Yeoh wrote:
> At 04:11 PM 11/10/2005 -0500, Tom Lane wrote:
> >A prepared transaction eats just about the same resources (other than an
> >active connection) as a live one. In particular it still holds its
> >locks, which makes leaving it around fo
>> SELECT * FROM foo WHERE bar::CHAR(3)='ABC';
> Your query is the same as using LIKE, so why not express it that way?
I want simply to select by first 3 characters. LIKE is too powerful and
unnessecary. LIKE requires
escaping % and ? characters in pattern.
I expected that making planner to use
hi all!
I have found a strange error.
panorama2=# select version();
version
PostgreSQL 8.1.0 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
(1 row)
I have next function in file ./f_sa
On Fri, Nov 11, 2005 at 11:31:37AM +0200, Andrus wrote:
> Best solution is as follows:
>
> Planner must use index
>
> CREATE TABLE foo ( bar CHAR(10) PRIMARY KEY );
>
> for queries like
>
> SELECT * FROM foo WHERE bar::CHAR(3)='ABC';
Your query is the same as using LIKE, so why not express it
I'm attempting to make a table function that starts returning to the
client before the entire result set is constructed.
>From the docs on plperl:
"Usually you'll want to return rows one at a time, both to speed up
startup time and to keep from queueing up the entire result set in
memory. You can
At 04:11 PM 11/10/2005 -0500, Tom Lane wrote:
Lincoln Yeoh writes:
> Is it OK to use PREPARE TRANSACTION and COMMIT PREPARED in order to have
> transactions that last longer than just a single web request?
> Previously it was usually a bad idea to keep database connections alive
> just to keep
Hugo wrote:
hi everybody,
Is it possible tu run vacuum from a plpgsql function ? I have a process that
copies a lot of data from a csv file with the copy command and at the end of
the function I would like to force a vacuun, is that possible.
I'm afraid not. VACUUM can't run inside a transacti
On 11.11.2005, at 9:33 Uhr, Guido Neitzer wrote:
Yes, as far as I know there is no other way of changing the locale
settings. Hopefully you are on Linux! If you deploy on Mac OS X or
*BSD it won't work even with a change.
I have to correct me: Hopefully you are not on Mac OS X. On Mac OS X,
> Ya know, this brings up an interesting question, would it be feasible to
> allow for a function of somekind to be applied as an argument to a
> primary key declaration? It would certainly be useful for character
> type pks in non-C locales.
Using this would require making non-standard changes
Andrew Schmidt wrote:
However, I've run into a problem where one query took about twice as
long as innodb. Some investigation and playing around with the query, I
ended up with a slightly different query but was about 3 times as fast
as innodb (and 5 times faster than the original query). I d
On 10.11.2005, at 21:31 Uhr, Michael Schuerig wrote:
My current conjecture is that I'd have to re-initialize the cluster
with
a utf-8 collation. Is this correct? Right now I don't have access to
the machine and can't check this.
Yes, as far as I know there is no other way of changing the loc
Scott Marlowe wrote:
> No, I wouldn't think one to one would be necessary. If you had a
> primary key that was case insensitive, for example, it would not map
> one to one. It would, in fact, be MORE greedy about matching, so
> that you could not have both a "Peter Eisentraut" and a "peter
> eise
55 matches
Mail list logo
