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
It still doesn't support raw device.
On Tue, Jun 9, 2009 at 1:06 PM, Lizzy M lizz...@gmail.com 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,
On Tue, Jun 9, 2009 at 8:49 AM, Gurjeet Singhsingh.gurj...@gmail.com 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
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
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
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:
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 this
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,
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 partition.
Running
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 partition.
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
the
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, my data directory is on
On 2009-06-04, Brandon Metcalf bran...@geronimoalloys.com 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
On 2009-06-05, David Fetter da...@fetter.org 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
On Tue, Jun 9, 2009 at 9:37 AM, tamanna
madaantamanna.ma...@globallogic.com 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
On Tue, Jun 9, 2009 at 4:14 AM, Dave Pagedp...@pgadmin.org wrote:
On Tue, Jun 9, 2009 at 8:49 AM, Gurjeet Singhsingh.gurj...@gmail.com 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
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 gryz...@gmail.com:
On Mon, Jun 8, 2009 at 6:57 AM, Anirban Palanirban@newgen.co.in 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
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
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 not
In response to tamanna madaan tamanna.ma...@globallogic.com:
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
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 ' ||
Great, quote_literal() solved it! It was so easy :)
Thx Richard
2009/6/9 Richard Huxton d...@archonet.com:
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()
2009/6/9 Brandon Metcalf bran...@geronimoalloys.com:
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
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 was
g == gryz...@gmail.com writes:
g 2009/6/9 Brandon Metcalf bran...@geronimoalloys.com:
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
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 execute
2009/6/9 Brandon Metcalf bran...@geronimoalloys.com:
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.
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 there
Bill Moran wmo...@potentialtech.com writes:
In response to tamanna madaan tamanna.ma...@globallogic.com:
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.)
2009/6/9 Grzegorz Jaśkiewicz gryz...@gmail.com:
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:
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
On Tue, 09 Jun 2009 08:24:01 -0700, Brandon Metcalf
bran...@geronimoalloys.com 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
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 may
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 zone
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 'UTC'
Chris Spotts rfu...@gmail.com 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
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
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
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
superuser. I
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 Kalininv...@mgcp.com 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
On Tue, Jun 9, 2009 at 10:35 PM, Tory M Blue tmb...@gmail.com 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
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
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
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
Ron Mayer rm...@cheapcomplexdevices.com 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)
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:
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
is does
Ron Mayer rm...@cheapcomplexdevices.com 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
Tom Lane wrote:
Ron Mayer rm...@cheapcomplexdevices.com 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
54 matches
Mail list logo
