On 21/07/2003 07:30 u15074 wrote:
To improve the performance of PostgreSQL, resp. to avoid too frequently
occuring
checkpoints, it is recommended to increase the number of wal files
(checkpoint_segments).
So I increased the number of checkpoint segments to be able to write a
lot of
data into the da
Hi!
I would like to create a database for products
catalogue. I have many products with different
specification.
e.g.
lamp A: Part no, Color, Raw Material, Wave length,
Vf(V)20mA, lv(ucd)10mA
ECG:Part no, Type, Iv, KHz, A, W, Im
Should I put these products in one table, or in
separate?
Best r
Hi,
Terence Ng wrote:
Hi!
I would like to create a database for products
catalogue. I have many products with different
specification.
e.g.
lamp A: Part no, Color, Raw Material, Wave length,
Vf(V)20mA, lv(ucd)10mA
ECG:Part no, Type, Iv, KHz, A, W, Im
Should I put these products in one table, or
On Mon, 2003-07-21 at 07:04, Terence Ng wrote:
> Hi!
>
> I would like to create a database for products
> catalogue. I have many products with different
> specification.
>
> e.g.
> lamp A: Part no, Color, Raw Material, Wave length,
> Vf(V)20mA, lv(ucd)10mA
>
> ECG:Part no, Type, Iv, KHz, A, W,
Receive the following error in PL/pgSQL
"Error: New Used in Non-Rule Query"
when attempting a comparison of NEW and OLD records in an update block:
IF TG_OP = ''UPDATE'' THEN
IF NEW != OLD THEN
...
...
END IF;
END IF;
How does
Zitat von Tom Lane <[EMAIL PROTECTED]>:
> A checkpoint pushes out all unwritten data since the last checkpoint.
> So yeah, it stands to reason that if you increase the time between
> checkpoints, each checkpoint will take longer. Whether this is really
> a problem is not clear --- the checkpoint
u15074 <[EMAIL PROTECTED]> writes:
> By the way, if you say, checkpointing is happening in the background, I don't
> know what causes the pauses.
Probably insufficient disk bandwidth. If you have two drives available,
try putting the WAL files (pg_xlog directory) on a different drive from
the dat
On 21/07/2003 13:04 Terence Ng wrote:
Hi!
I would like to create a database for products
catalogue. I have many products with different
specification.
e.g.
lamp A: Part no, Color, Raw Material, Wave length,
Vf(V)20mA, lv(ucd)10mA
ECG:Part no, Type, Iv, KHz, A, W, Im
Should I put these products i
Zitat von Tom Lane <[EMAIL PROTECTED]>:
> Probably insufficient disk bandwidth. If you have two drives available,
> try putting the WAL files (pg_xlog directory) on a different drive from
> the data files. Assuming you have adequate RAM, updates will be mainly
> limited by writes to WAL, while ch
Perhaps I'm missing something, but it appears that there is no way to
force the 'tuples-only' toggle in psql to either state. I think the same
may be true of other toggles.
This creates problems when running scripts via the \i command.
--
Mike Nolan
---(end of broadca
Hi,
I have a doubt regarding WAL.
Let's say I have only one wAL segment of 16MB and in a single transaction I
put 20MB of data, say a text file dump inside a transaction.
How does WAL handles this situation from POV of using/reusing WAL space and
ensuring consistency of data in table?
Does it
u15074 <[EMAIL PROTECTED]> writes:
> Can you specify more exactly what you mean with update rate? I moslty perform
> inserts on the database (is that what you mean?).
Sure, inserts/updates/deletes.
> Also I do not understand, why checkpoint does not touch WAL, but RAM. I thought
> that a checkpo
Hmm.. I can't believe I missed that. While that exact macro wouldn't
apply in my situation (because I fetch the value from a field in a tuple and
not the argument of a function), the underlying concept is the same as
what I would need. Now I do not need to feel the wrath of unnecessary
memor
elein wrote:
Quel rules.
PostQUEL ... we should have kept a compatibility mode for that.
Jan
[EMAIL PROTECTED]
(For those of you who do not know, quel was the original
query language used by postgres. And ingres.)
On Sun, Jul 13, 2003 at 10:12:16AM -0700, Vincent Hikida wrote:
Oops forgot to CC
How can you have two tables with the same name in one database ??
How do you differentiate them when you use it in queries ??
> X-Original-To: [EMAIL PROTECTED]
> Date: Sun, 20 Jul 2003 21:23:12 +0100 (BST)
> From: "Nigel J. Andrews" <[EMAIL PROTECTED]>
> X-Sender: [EMAIL PROTECTED]
> To: [EMAIL
On Wed, 16 Jul 2003, Jon Brazus wrote:
>
> Does anyone know of a way to pass more than 32 parameters to a plpgsql
> function? The 7.3 release documentation states that fuctions can now
> take up to 32 parameters "by default", which implies that perhaps this
> can be changed with a tuning para
On Thu, 17 Jul 2003, Kallol Nandi wrote:
> How can I have a scheduled vacuum and backup of the databases in PostgreSql.
> Does someone know it already?
> I need it urgently.
Use cron (I assume you're running Unix.)
A simple crontab entry to run 'vacuumdb -a -z -f' and pg_dump should do.
'man cr
On Mon, 14 Jul 2003 [EMAIL PROTECTED] wrote:
> Hi everybody,
> maybe I'm too fool, but I didn't succeed in downloading Postgres by any
> mirror-page, because I haven't any idea for logging in.
> I tried as well anonymous login with my email-address, but it failed the same
> way.
> Does anybody kno
This one is irritating. Here's some psql output:
dumps=# \d fal_profdel
Table "fal_profdel"
Attribute | Type | Modifier
---+--+--
sid
pg_dump: query to get data of sequence "profile_id_seq" returned name
"profiles_id_seq"
I renamed a sequence using PgAdmin II from profiles_id_seq to profile_id_seq.
Any suggestions on getting everything synched to the proper names again?
CG
__
Do you Yahoo!?
SB
On Mon, 21 Jul 2003, Kathy Zhu wrote:
> How can you have two tables with the same name in one database ??
> How do you differentiate them when you use it in queries ??
In different schemas. For example:
create schema first;
create schema second;
create table first.atable ( id serial primary key
On Mon, 21 Jul 2003, Philip Greer wrote:
> dumps=# \d fal_profdel
>Table "fal_profdel"
> Attribute | Type | Modifier
> ---+--+--
> sid | character(4) | not null
> card_num | character(19)|
Thanks for the response:
I took a look at the table with 'vacuum verbose analyze', here's the results:
dumps=# vacuum verbose analyze fal_profdel;
NOTICE: --Relation fal_profdel--
NOTICE: Pages 62232: Changed 0, reaped 205, Empty 0, New 0; Tup 4664867: Vac 0,
Keep/VTL 0/0, Crash 0, UnUsed 447,
Uh, no one has come up with a better solution, so it will be in 7.4 too.
---
Sean Mullen wrote:
>
> What is the 'status' of DB_USER_NAMESPACE?
>
> Is it still a temporary measure and is it safe to rely on it?
>
>
> Sean.
On Monday 21 July 2003 19:51, Philip Greer wrote:
> Thanks for the response:
>
> I took a look at the table with 'vacuum verbose analyze', here's the
> results:
>
> dumps=# vacuum verbose analyze fal_profdel;
[snip]
> Then - afterwards, I ran the explain again:
>
> dumps=# explain select card_num f
Philip Greer <[EMAIL PROTECTED]> writes:
> WTF? Why would a vacuum be necessary in order for it to start using the index?
It's not the VACUUM that's necessary; it's the ANALYZE. The query
planner uses table statistics to make its decisions, and ANALYZE is
what collects those statistics. Without
On Mon, 21 Jul 2003, Philip Greer wrote:
> Thanks for the response:
>
> I took a look at the table with 'vacuum verbose analyze', here's the results:
>
> dumps=# vacuum verbose analyze fal_profdel;
> NOTICE: --Relation fal_profdel--
> NOTICE: Pages 62232: Changed 0, reaped 205, Empty 0, New 0; T
Philip,
In order for psql to work out the most effective way to run queries it
relies on statistics about the size of your tables (amounst other
things).
Running VACUUM ANALYZE does two things:
The vacuum removes any tuples you have deleted from the database (before
this i think they are just mark
Doug McNaught wrote:
> It's not the VACUUM that's necessary; it's the ANALYZE. The query
> planner uses table statistics to make its decisions, and ANALYZE is
> what collects those statistics. Without an ANALYZE the planner will
> make default assumptions that are rarely correct. :)
I am not th
Andrew Ayers <[EMAIL PROTECTED]> writes:
> Doug McNaught wrote:
> > It's not the VACUUM that's necessary; it's the ANALYZE. The query
> > planner uses table statistics to make its decisions, and ANALYZE is
> > what collects those statistics. Without an ANALYZE the planner will
> > make default a
Well duh. Crap. I remember that NOW that I've read everyones comments (thanks by the
way!). I do remember reading that, and have placed the 'vacumedb -z' command in
crontabs on databases in the past. Just forgot all about that - I guess it is because
most of the databases I've set up on postgres
> So - are you saying that if you have a table, and you create an index on
> that table, you need to perform an ANALYZE in order for PG to use the
> index. Otherwise, the index goes unused (or used improperly)?
it is easy enough to demonstrate that creating an index will result
in immediate improv
32 matches
Mail list logo
