William Yu <[EMAIL PROTECTED]> writes:
> Benjamin Arai wrote:
>> What is the current maximum number of tables per database? Also, does
>> having more tables slow down performance in any way?
> For most cases, the answer is no. However, once you get near 6 figure
> table counts, pg_catalog ends
On Sat, Dec 10, 2005 at 09:02:39PM -0600, Foster, Stephen wrote:
> I did see last week something on PLPGSQL and read through that. But
> there has to be something out there that goes in depth on the
> SQL/Function command set(Speaking of functions/procedures).
The standard functions are described
Benjamin Arai
wrote on Saturday, December 10, 2005 3:37 PM
> ... On the other hand there is a weekly update (This is the
> problem) that updates all of the modified records for a bunch of
> finacial data such as closes and etc. For the most part they are
> records of the type name,date,value.
This could be an old conversation for most. I've used PostgreSQL for a
while but I haven't fully use the Procedure/Functions to it fullest
until now. I need to migrate a MS-SQL 2000 database to PostgreSQL.
I've read as much as I could find but I seem to be missing something.
I did see last week
On Saturday 10 December 2005 19:28, Jaime Casanova wrote:
> On 12/10/05, Benjamin Arai <[EMAIL PROTECTED]> wrote:
> > To be more specific, there are two types of commands that are run on
> > the system. There are application commands that do all different types
> > of joins and etc but for the mo
On 12/10/05, Benjamin Arai <[EMAIL PROTECTED]> wrote:
> To be more specific, there are two types of commands that are run on
> the system. There are application commands that do all different types
> of joins and etc but for the most part are fast enough to meet user
> expectations. On the other
To be more specific, there are two types of commands that are run on
the system. There are application commands that do all different types
of joins and etc but for the most part are fast enough to meet user
expectations. On the other hand there is a weekly update (This is the
problem) that
On Sat, Dec 10, 2005 at 03:22:47PM -0800, Benjamin Arai wrote:
> My issue actually stems from the fact that I cannot do large weekly
> updates on fast enough to meet a weekend window for the following work
> week. I am currently using a machine with a raid 1, 4GB RAM, and dual
> opteron. I cou
My issue actually stems from the fact that I cannot do large weekly
updates on fast enough to meet a weekend window for the following work
week. I am currently using a machine with a raid 1, 4GB RAM, and dual
opteron. I could go 0+1 but peroformance increase is only about 20%
from the benchma
Andrew J. Kopciuch wrote:
>>You could write a one trigger for the table to handle both.
>
> Something like this :
[...]
> CREATE OR REPLACE FUNCTION multi_tsearch2() RETURNS TRIGGER AS '
[...]
I tested the function today and it's exactly what I had in mind.
Works perfectly!
Thanks, Stephan
sign
Benjamin Arai wrote:
What is the current maximum number of tables per database? Also, does
having more tables slow down performance in any way?
For most cases, the answer is no. However, once you get near 6 figure
table counts, pg_catalog ends up being pretty massive. The problem is
that the
What is the current maximum number of tables per database? Also, does
having more tables slow down performance in any way?
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
On Sat, 10 Dec 2005, Benjamin Smith wrote:
> A few questions:
>
> 1) Let's assume that I have some multipile foreign keys, and I join on three
> values. For example:
>
> Create table gangsters (
> name varchar not null,
> birthdate integer not null,
> shirtnumber integer not nul
Marcin Inkielman <[EMAIL PROTECTED]> writes:
> I am migrating a relativly huge database from postgres 7.2 to 8.0. I
> need to alter schema
> for sth about 500 tables and twice as many other objects. Do I need to
> sth other on a new database than:
I'd suggest updating to 8.1 (where there's ALTER S
Hi!
I am migrating a relativly huge database from postgres 7.2 to 8.0. I
need to alter schema
for sth about 500 tables and twice as many other objects. Do I need to
sth other on a new database than:
create schema ... ;
update pg_class set relnamespace =$oid_of_new_schema where
relnamespace=$oid_o
Simon Riggs <[EMAIL PROTECTED]> writes:
> You'll find response times spike somewhat during Checkpoints. We've been
> working to reduce this effect for some time and there is still more work
> to be done.
>
> Tune your wal settings and bgwriter to improve things, plus upgrade to
> 8.1 which has m
And, it's exactly as fast on the new, dual-proc Opteron as the aging P4. 2.2
seconds. It's literally within 1 ms time! (2,206 ms vs 2,207 ms) Throwing
more RAM at it makes no difference.
WTF??!?!?
Well from a postgres perspective you are still only using one CPU for
this query. Are yo
I have a small company growing fast, selling a product based largely on
Postgres. We have a rapidly growing database with (currently) 117 tables.
Our primary server, an aging system based around an IDE, 2.4 Ghz P4, is being
replaced by a new, 10k SCSI, dual-proc AMD opteron/64, with 4 GB of ECC
On Fri, 2005-12-09 at 14:29 +0100, Baldur Norddahl wrote:
> I noticed that sometimes we seem to have a problem with simple queries
> that take a long time to execute. For example "select * from config
> where key='abc'" which normally only takes a few milliseconds, but in
> some rare cases sudd
19 matches
Mail list logo
