Hello,
I have an problem: can postgresql store its data on the raw disks now?
I have checked the mail list and manual, but haven’t found the
answer. In some early mails, they mentioned pg didn’t support this
character. But how about now? Raw disk may reduce the risks brought by
fi
It still doesn't support raw device.
On Tue, Jun 9, 2009 at 1:06 PM, Lizzy M wrote:
> Hello,
>
>I have an problem: can postgresql store its data on the raw disks
> now?
>
>I have checked the mail list and manual, but haven’t found the
> answer. In some early mails, they mentioned
On Tue, Jun 9, 2009 at 8:49 AM, Gurjeet Singh wrote:
> It still doesn't support raw device.
Nor is it ever likely to. Filesystems are vastly superior now than
when certain other DBMSs were designed to use raw devices, and for
PostgreSQL to replace the average filesystem now with something as
relia
Hi all !
Reading through the list of settings returned by "SHOW ALL", I noticed
the "block_size" variable, which defaults to 8192.
Running on Windows Server, my data directory is on an NTFS partition.
Running CHKDSK on this partition tells me that there are "4096 bytes in
each allocation unit
Hello,
I have some columns containig list of codes (e.g. 'Af45De Uz76 I98ht ...
')
and I'd like to build full text search indexes on them.
As these strings are basically a list of IDs , I don't need any
dictionary.
I've built an own simplified parser whose output is sufficient.
My concern is a
Hello,
I've found a dirty hack with custom GUC variables here:
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00643.php
Although dirty, it seems that it beats the windowing performances of
8.4.
So I wonder if there are any concern about this...
Cheers,
Marc Mamin
--
Sent via pg
Marc,
we'll probably add option to simple dictionary for 8.5, but I think
if you were able to write your own parser it'd be not difficult to
write 'simplest' dictionary, which does nothing. Just take simple dictionary
and remove lowercasing :)
Oleg
On Tue, 9 Jun 2009, Marc Mamin wrote:
Hello,
postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
> Hi all !
>
> Reading through the list of settings returned by "SHOW ALL", I noticed
> the "block_size" variable, which defaults to 8192.
>
> Running on Windows Server, my data directory is on an NTFS partition.
> Running CHKDSK on
Marc
very concerned about the 'dirty' classification
any suggestions?
Martin Gainty
__
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so
Bruce Momjian wrote:
> postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
>> Hi all !
>>
>> Reading through the list of settings returned by "SHOW ALL", I noticed
>> the "block_size" variable, which defaults to 8192.
>>
>> Running on Windows Server, my data directory is on an NTFS part
Bruce Momjian - br...@momjian.us a écrit :
postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
Reading through the list of settings returned by "SHOW ALL", I noticed
the "block_size" variable, which defaults to 8192.
Running on Windows Server, my data directory is on an NTFS partiti
postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
> Bruce Momjian - postgresqlgeneral.domain.thewild_cod...@spamgourmet.com a
> ?crit :
> > postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
> >> Reading through the list of settings returned by "SHOW ALL", I noticed
> >>
Craig Ringer wrote:
> Bruce Momjian wrote:
> > postgresqlgeneral.domain.thewild_cod...@spamgourmet.com wrote:
> >> Hi all !
> >>
> >> Reading through the list of settings returned by "SHOW ALL", I noticed
> >> the "block_size" variable, which defaults to 8192.
> >>
> >> Running on Windows Server,
On 2009-06-04, Brandon Metcalf wrote:
> Is there a way when creating a table to limit it to one row? That is,
> without using a stored procedure?
>
> I searched the documentation, but didn't find anything.
create a unique index, and a constraint to a single value on one of
the columns :)
--
S
On 2009-06-05, David Fetter wrote:
> On Thu, Jun 04, 2009 at 11:11:29AM -0400, Bruce Momjian wrote:
>> Jennifer Trey wrote:
>> > Hi,
>> > What file should I be working with?
>>
>> Just shut down the server and move the directory whever you want and
>> restart the server. There are no file conten
On Tue, Jun 9, 2009 at 9:37 AM, tamanna
madaan wrote:
> Hi
>
> I am using postgres 8.1.2 with slony 1.1.5 used for replication between two
> nodes. Very high number of db operations like (2.8 million inserts, 1.4
> million update and 4.5 lakhs deletes.) are being done on db in one
> transaction and
On Tue, Jun 9, 2009 at 4:14 AM, Dave Page wrote:
> On Tue, Jun 9, 2009 at 8:49 AM, Gurjeet Singh wrote:
>> It still doesn't support raw device.
>
> Nor is it ever likely to. Filesystems are vastly superior now than
> when certain other DBMSs were designed to use raw devices, and for
> PostgreSQL to
Hi
I am using postgres 8.1.2 with slony 1.1.5 used for replication between two
nodes. Very high number of db operations like (2.8 million inserts, 1.4 million
update and 4.5 lakhs deletes.) are being done on db in one transaction and this
is repeated for 5-6 times a day at an interval of let
2009/6/8 Grzegorz Jaśkiewicz :
> On Mon, Jun 8, 2009 at 6:57 AM, Anirban Pal wrote:
>> Dear all,
>>
>> Our software use postgres as backend database. It works fine, strange thing
>> is that, it creates so many temporary schemas under schema tab, names like
>> pg_toast, pg_toast_temp_1 like this upt
Hello list.
I'm a newbie with plpgsql, so I'm sorry for doing stupid questions...
I have a situation whit one table where items are related to two other
tables through a common id (unique in the first table) and the table
name. Whenever the user execute an operation on an item of the first
one ("pr
g == gryz...@gmail.com writes:
g> just change whatever you are storing to be in vertical structure,
g> instead of horizontal. so instead of create table foo(a int, b int, c
g> int, etc), try:
g> create table foo(name varchar, val int);
g> common mistake I've seen committed by people..
I'm
In response to "tamanna madaan" :
>
> I am using postgres 8.1.2 with slony 1.1.5 used for replication between two
> nodes. Very high number of db operations like (2.8 million inserts, 1.4
> million update and 4.5 lakhs deletes.) are being done on db in one
> transaction and this is repeated for
G. Allegri wrote:
ERROR: Column 'lets_try' does not exist
LINE 1: INSERT INTO seconda (nome) VALUES ('lets_try')
My function and trigger are:
CREATE OR REPLACE FUNCTION fun1() RETURNS TRIGGER AS
$primaprova$
DECLARE
nome varchar;
BEGIN
IF (TG_OP='INSERT') THEN
execute 'INSERT INTO ' || NEW.tab
Great, quote_literal() solved it! It was so easy :)
Thx Richard
2009/6/9 Richard Huxton :
> G. Allegri wrote:
>>
>> ERROR: Column 'lets_try' does not exist
>> LINE 1: INSERT INTO seconda (nome) VALUES ('lets_try')
>>
>> My function and trigger are:
>>
>> CREATE OR REPLACE FUNCTION fun1() RETURNS
2009/6/9 Brandon Metcalf :
> I'm not sure I follow how this solves the problem.
Well, surely if you just need one row, you need single value per key.
And that's the, imo , better solution to that problem, than limiting
number of rows.
--
GJ
--
Sent via pgsql-general mailing list (pgsql-gene
Stephan, you're rigth. It was just a first try. In the real situation
"seconda" and "terza" have a prima_id column. So the right one is:
execute 'UPDATE '|| NEW.tabella ||' SET nome='||
quote_literal(NEW.nome) ||' WEHERE prima_id=' || NEW.id || ';';
I though that double apices would quote. That w
g == gryz...@gmail.com writes:
g> 2009/6/9 Brandon Metcalf :
g> > I'm not sure I follow how this solves the problem.
g> Well, surely if you just need one row, you need single value per key.
g> And that's the, imo , better solution to that problem, than limiting
g> number of rows.
Hm. Ma
On Tue, 9 Jun 2009, G. Allegri wrote:
> Hello list.
> I'm a newbie with plpgsql, so I'm sorry for doing stupid questions...
> I have a situation whit one table where items are related to two other
> tables through a common id (unique in the first table) and the table
> name. Whenever the user exec
2009/6/9 Brandon Metcalf :
>
> CREATE TABLE foo (
> start DATE,
> length VARCHAR(10),
> );
>
> I need to be able to get one value for each column at any given time.
> Specifically, I need to get a value for start and add the value for
> length to get a time period. Since your approach wo
g == gryz...@gmail.com writes:
g> If you want to store period of time, why store it as varchar ?
g> just store two rows
g> create table foo(
g> n varchar,
g> val date
g> );
g> and store two rows:
g> "start", now(),
g> "end", now()+'something '::interval
g> Wouldn't that do, or is
Bill Moran writes:
> In response to "tamanna madaan" :
>>
>> I am using postgres 8.1.2 with slony 1.1.5 used for replication
>> between two nodes. Very high number of db operations like (2.8
>> million inserts, 1.4 million update and 4.5 lakhs deletes.) are being
>> done on db in one transaction
2009/6/9 Grzegorz Jaśkiewicz :
> The slony tables perhaps should be vacuumed too.
>
slony vacuum's its own tables as necessary.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Hello,
i have reading in the mailing list any messages where different people use this
format to establish a functional index in a column using a type cast.
CREATE INDEX fecha_creacion_ordtrab ON orden_trabajo_cabecera USING btree
((time_stamp_creacion::date));
but in my postgresql 8.3 vers
On Tue, 09 Jun 2009 08:24:01 -0700, Brandon Metcalf
wrote:
CREATE TABLE foo (
start DATE,
length VARCHAR(10),
);
I need to be able to get one value for each column at any given time.
CREATE UNIQUE INDEX u ON foo ((start IS NOT NULL));
You would just make sure you SELECT FROM f
lizz...@gmail.com (Lizzy M) writes:
> I have an problem: can postgresql store its data on the raw disks now?
>
> I have checked the mail list and manual, but havent found the
> answer. In some early mails, they mentioned pg didnt support this
> character. But how about now? Raw disk m
>CREATE INDEX fecha_creacion_ordtrab ON orden_trabajo_cabecera USING btree
>((time_stamp_creacion::date));
>
>but in my postgresql 8.3 version i get this error:
>
>ERROR: functions in index expression must be marked IMMUTABLE
If your time_stamp_creacion is a timestamp with time
Linos escribió:
> CREATE INDEX fecha_creacion_ordtrab ON orden_trabajo_cabecera USING btree
> ((time_stamp_creacion::date));
>
> but in my postgresql 8.3 version i get this error:
>
> ERROR: functions in index expression must be marked IMMUTABLE
You can make it work by adding an AT TIME ZONE 'U
"Chris Spotts" writes:
>> CREATE INDEX fecha_creacion_ordtrab ON orden_trabajo_cabecera USING btree
>> ((time_stamp_creacion::date));
>>
>> but in my postgresql 8.3 version i get this error:
>>
>> ERROR: functions in index expression must be marked IMMUTABLE
> If your time_stamp
Yes it seems you have reason Chris, i have been using 'timestamp with time zone'
without need it because i have read in the mailing list was good practice
because maybe one day you use the database in more timezones but i ever use the
app in the same timezone so i will convert the column datatyp
Good day,
I'm having one heck of a time here. I'm looking for a clean solution
to issue a COPY statement from a remote system. (because I really
don't want to play the ssh, sudo spiel).
It's evident that pg_connect doesn't like the \copy command (it's a no
go), however it is okay with the COPY co
> I must be able to do this from a client system, I must be able to lock
> down the db user to limited access and I can take care of permissions
> on the client end, but postgres seems to be slightly rigid in regards
> to the COPY command and the fact that one can't really have a jailed
> superuse
> however the COPY
> command requires superuser and I really don't want to open up the DB
> from a remote system with Superuser access.
COPY FROM STDIN does not need superuser privileges.
On Tue, Jun 9, 2009 at 11:31 AM, Vyacheslav Kalinin wrote:
>> however the COPY
>> command requires superuser and I really don't want to open up the DB
>> from a remote system with Superuser access.
>
> COPY FROM STDIN does not need superuser privileges.
>
Thanks guys, the problem with copy from or
On Tue, Jun 9, 2009 at 10:35 PM, Tory M Blue wrote:
>
> Thanks guys, the problem with copy from or to is that it creates an
> array and thus puts a load of stuff in memory, it's possible the file
> will get huge and I can't take that memory hit.
>
> I'll look again and see if I missed something
>
Forgot about COPY command in my previous reply:
$conn = pg_pconnect("dbname=foo");
$fd = fopen('file.dat', 'r');
pg_query($conn, "copy bar from stdin");
while (!feof($fd)) {
pg_put_line($conn, fgets($fd));
}
fclose($fd);
pg_put_line($conn, "\\.\n");
pg_end_copy($conn);
Hi!
Is it possible in Postgres to specify aliases for various DB objects, such as
tables, views, sequences, etc.? (For now I would like to create them for
sequences.)
What I mean is something like in Oracle, such as
create alias my_sequence_alias for my_sequence;
select nextval('my_sequence_al
Hi All,
I decided to go with the following fix. Instead of strait delete and insert
statements I am gonna use stored procedures for delete and insert:
CREATE OR REPLACE FUNCTION delete_group(integer)
RETURNS void AS
$BODY$
BEGIN
delete from infotest where infotest.groupid = $1;
No, it's not possible, pgSQL does't have a CREATE ALIAS -syntax
You could put this function into another function to create sort of an
alias, but that wouldn't make to much sense.
Frank
Op 9 jun 2009, om 22:03 heeft Agoston Postgres het volgende geschreven:
Hi!
Is it possible in Postgres
Agoston Postgres wrote:
> Hi!
>
> Is it possible in Postgres to specify aliases for various DB objects, such as
> tables, views, sequences, etc.? (For now I would like to create them for
> sequences.)
>
> What I mean is something like in Oracle, such as
>
> create alias my_sequence_alias for m
Ron Mayer writes:
> Tom Lane wrote:
>> That is a bit odd, especially seeing that eg. '1' hour to second
>> comes out as 1 second. What's making it do that?
> Code-wise, it seems because around line 2906 in DecodeInterval:
> switch (range) ...
> case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR)
I wrote:
> I'm inclined to say that these two cases are out of line with what
> the rest of the code does and we should change them.
Specifically, I'm thinking of a patch like this:
Index: datetime.c
===
RCS file: /cvsroot/pgsql/src/
Tom Lane wrote:
> I wrote:
>> I'm inclined to say that these two cases are out of line with what
>> the rest of the code does and we should change them.
> ...
> Now, all three of these cases throw "invalid input syntax" in 8.3,
> so this is not a regression from released behavior. The question
>
Ron Mayer writes:
> It still accepts one odd input that 8.3 rejected:
> regression=# select interval '1 1' hour;
> Perhaps the additional patch below fixes that?
Hmm, not sure about that one. We decided a week or two back that we
don't want the thing discarding higher-order field values, and
Tom Lane wrote:
> Ron Mayer writes:
>> regression=# select interval '1 1' hour;
>
> Hmm, not sure about that one. We decided a week or two back that we
> don't want the thing discarding higher-order field values, and this
> seems pretty close to that. As the code is set up (plus my patch)
>
Mogwai ERDesigner NG is a Java based entity releationship design
tool. It includes the following key features:
* is based on Java and can be run on Windows and Unix systems
* has a powerful WYSIWYG for physical database design
* handles tables, relations, indexes and comments
* supports a central
55 matches
Mail list logo
