Hi,
novnov wrote:
OK, this has been very informative and I'd like to thank the three of you.
Asynchronous replication to readonly slaves is something I will look into.
I've never touched posgtres replication; and Scott mentioned that he was not
familiar with PGCluster, so there must be some ot
Hello
We plProxy to split our database into partitions. See Kristo's blog's about
that at http://kaiv.wordpress.com/.
For replication we use Londiste in SkyTools package. SkyTools contains
several more scripts that are useful when buildin large and complex systems
running on large number of serve
OK, this has been very informative and I'd like to thank the three of you.
Asynchronous replication to readonly slaves is something I will look into.
I've never touched posgtres replication; and Scott mentioned that he was not
familiar with PGCluster, so there must be some other replication syst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/07 19:58, novnov wrote:
> You're right, that's not how I understood your partitioning question. I'd not
> be eager to implement that kind of split in the db, though I can see that
> it's an example of how to spread the load around.
>
> But ba
On 9/8/07, novnov <[EMAIL PROTECTED]> wrote:
> But basically, it seems that the answer to one of my questions is that there
> is currently no way with postgres to spread a single database over multiple
> servers, ala a loadbalanced apache cluster, where requests are forwarded to
> different boxes.
You're right, that's not how I understood your partitioning question. I'd not
be eager to implement that kind of split in the db, though I can see that
it's an example of how to spread the load around.
But basically, it seems that the answer to one of my questions is that there
is currently no wa
On 9/8/07, novnov <[EMAIL PROTECTED]> wrote:
>
> Yes the trx would be akin to banking operations.
>
> This is good: "Can you partition your data to multiple servers?" That's kind
> of my question! I've not dealt with RAC, data partitioning, any of those
> topics; just haven't had exposure. But sin
Yes the trx would be akin to banking operations.
This is good: "Can you partition your data to multiple servers?" That's kind
of my question! I've not dealt with RAC, data partitioning, any of those
topics; just haven't had exposure. But since you're asking me if the data
can be partitioned to d
On 9/8/07, novnov <[EMAIL PROTECTED]> wrote:
>
> Yes, I realize that scaling must be a large and complicated topic. And that
> PostgresSQL is not as scaleable as Oracle etc.
Depends on how we're defining scalability. :)
I didn't explicitly say that RAC will outscale postgresql. It's just
one ap
Yes, I realize that scaling must be a large and complicated topic. And that
PostgresSQL is not as scaleable as Oracle etc.
I know after reading your post that Postgres cannot match RAC. I'm still not
sure if Postgres can operate a database from more than one box, at all. If
it can, how? I mean is
On 9/8/07, novnov <[EMAIL PROTECTED]> wrote:
>
> What happens when a database needs to scale beyond a single server? Is this
> something PostgreSQL can do?
>
> Further, does a database need to be designed differently if it's going to be
> used on more than one server? I know there are many issues t
What happens when a database needs to scale beyond a single server? Is this
something PostgreSQL can do?
Further, does a database need to be designed differently if it's going to be
used on more than one server? I know there are many issues that might effect
a database's ability to scale; but sp
Matt
>
>> Original Message
>> Subject: Re: [GENERAL] Scalability
>> From: "Joshua D. Drake" <[EMAIL PROTECTED]>
>> Date: Sat, October 28, 2006 8:38 pm
>> To: Bill <[EMAIL PROTECTED]>
>> Cc: pgsql-general@postgresql.or
Top at 350-400 concurrent connections! Although more than my project's
peak estimates, it is a bit discomforting. Are there any *promising*
load testing numbers with Windows 2003? I'd be happy to share results
from my simulations.
Matt
> Original Message
> Subje
>> So in answer to your question, in general -- no the process
>> methodology we use does not limit scalability and it makes our code
>> base much simpler that the equivalent threading model.
>>
>> Sincerely,
>>
>> Joshua D. Drake
>
> Thanks. How much memory does PostgreSQL consume with 2000 con
"Joshua D. Drake" wrote:
> Bill wrote:
> > I am new to PostgreSQL and just beginning to learn the product. I
> > will probrobably be using it exclusively on Windows.
> >
> > I was surprised to learn that PostgreSQL creates a new process for
> > each connection. Doesn't this severely limit its sca
On Oct 29, 2006, at 02:31 , Bill wrote:
I was surprised to learn that PostgreSQL creates a new process for
each
connection. Doesn't this severely limit its scalability by consuming
resources rapidly on the server as the number of user increases?
On Windows, yes; Win32 processes carry a not i
Bill wrote:
> I am new to PostgreSQL and just beginning to learn the product. I will
> probrobably be using it exclusively on Windows.
>
> I was surprised to learn that PostgreSQL creates a new process for each
> connection. Doesn't this severely limit its scalability by consuming
> resources rapi
I am new to PostgreSQL and just beginning to learn the product. I will
probrobably be using it exclusively on Windows.
I was surprised to learn that PostgreSQL creates a new process for each
connection. Doesn't this severely limit its scalability by consuming
resources rapidly on the server as the
To me, the issues of scalability come from a management perspective.
I'm dealing with a schema that has tens of thousands of tables, but
they are inherited from a relatively small set of superclass tables.
I imagine there are similar issues to managing schemas as there are to
managing subclass
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Christopher Browne replied:
>> If you've got tens of thousands of relations, the tab completion code
>> has to draw the whole list of relations from pg_class into memory and
>> "marshal" it into a form usable by GNU Readline.
> Well, it's actuall
Thanks to all who've responded to my concern about scalability with
large numbers of tables. I am reasonably reassured.
I don't really care about the tab-completion speed - it's just that its
slowness was my "heads-up" to the fact that there could be something
related to number of tables to wo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phil Endecott wrote:
> For example I find that tab-completion in psql is now unusably slow
...
Christopher Browne replied:
> If you've got tens of thousands of relations, the tab completion code
> has to draw the whole list of relations from pg_clas
Christopher Browne wrote:
Oops! [EMAIL PROTECTED] (Phil Endecott) was seen spray-painting on a wall:
I have a single database with one schema per user. Each user has a
handful of tables, but there are lots of users, so in total the
database has thousands of tables.
If you've got tens of thousands
I'm pretty sure that slowness of tab completion has little to do with
the performance of the filesystems.
If you've got tens of thousands of relations, the tab completion code
has to draw the whole list of relations from pg_class into memory and
"marshal" it into a form usable by GNU Readline. TH
Oops! [EMAIL PROTECTED] (Phil Endecott) was seen spray-painting on a wall:
> Dear Postgresql experts,
>
> I have a single database with one schema per user. Each user has a
> handful of tables, but there are lots of users, so in total the
> database has thousands of tables.
>
> I'm a bit concerned
On Sun, 20 Feb 2005, Phil Endecott wrote:
Dear Postgresql experts,
I have a single database with one schema per user. Each user has a handful
of tables, but there are lots of users, so in total the database has
thousands of tables.
I'm a bit concerned about scalability as this continues to grow
On Sun, 2005-02-20 at 10:45, Lincoln Yeoh wrote:
> I'm not an expert.
>
> Turn off tab completion? It's probably scanning through all the possible
> table names and the algorithm used is probably not designed for that
> number. And with 42000 tables, tab completion may not be that helpful.
>
>
Lincoln Yeoh wrote:
> I'm not an expert.
>
> Turn off tab completion? It's probably scanning through all the
> possible table names and the algorithm used is probably not designed
> for that number. And with 42000 tables, tab completion may not be
> that helpful.
>
> Don't use ext2/ext3? There
I'm not an expert.
Turn off tab completion? It's probably scanning through all the possible
table names and the algorithm used is probably not designed for that
number. And with 42000 tables, tab completion may not be that helpful.
Don't use ext2/ext3? There are other filesystems on Linux which
Dear Postgresql experts,
I have a single database with one schema per user. Each user has a
handful of tables, but there are lots of users, so in total the database
has thousands of tables.
I'm a bit concerned about scalability as this continues to grow. For
example I find that tab-completion
On Thu, 18 Sep 2003, Duffey, Kevin wrote:
> We are looking for information regarding any capabilities of PostgreSQL
> in regards to scalability. Ideally we want to be able to scale in both
> directions. What sort of solutions are out there for either or both
> directions of scalability? Specifi
We are looking for information regarding any capabilities of PostgreSQL in regards to
scalability. Ideally we want to be able to scale in both directions. What sort of
solutions are out there for either or both directions of scalability? Specifically,
open-source solutions would be most in need,
Jan Ploski <[EMAIL PROTECTED]> writes:
> Do I assume correctly that CPU will be the earliest limiting factor
> for a database (if we have a reasonable amount of memory in the box)?
Depends on your query mix. If you have a lot of updates then I'd
recommend spending plenty of money on fast disk dr
ly, I find that CPU is rarely the bottleneck. It is usually
either lack of memory or the speed of the disks...
- Original Message -
From: "Jan Ploski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 14, 2001 1:54 PM
Subject: [GENERAL] Scalability
&
Hello,
When large databases, complex queries and frequent access are combined,
the database backend may become a performance bottleneck. This is quite
obvious.
Do I assume correctly that CPU will be the earliest limiting factor
for a database (if we have a reasonable amount of memory in the box)
M Simms wrote on Tue, 15 Jun 1999 19:58:28 BST
>> Dear Folks,
>>
>> We have been running 6.4.2 under Linux on a dual Xeon box
>> with mostly good success. Our current dataset is 20 million records
>> of mostly numerical data (56 fields of floats [70%], ints [20%] and
>> a few text fields [10%])
> Dear Folks,
>
> We have been running 6.4.2 under Linux on a dual Xeon box
> with mostly good success. Our current dataset is 20 million records
> of mostly numerical data (56 fields of floats [70%], ints [20%] and
> a few text fields [10%]). The performance is acceptable, the only
> problem
38 matches
Mail list logo
