On Jun 30, 2010, at 11:12 AM, t...@exquisiteimages.com wrote:
> I read a post
> earlier today that mentioned in passing that it was better to have a
> faster processor than more cores.
This really depends on your workload and how much you value latency vs.
throughput. If you tend to have a lot
Thanks for all of the input everyone.
I believe I am going to put together a test case using schemas and
partitioning and then doubling the amount of data currently in the system
to give me an idea of how things will be performing a couple of years down
the road.
I was looking at a server using t
t...@exquisiteimages.com writes:
> I am wondering how I should architect this in PostgreSQL. Should I follow
> a similar strategy and have a separate database for each client and one
> database that contains the global data?
As others said already, there's more problems to foresee doing so that
t
On Fri, Jun 25, 2010 at 3:36 PM, wrote:
> I am in the process of moving a system that has been built around FoxPro
> tables for the last 18 years into a PostgreSQL based system.
>
> Over time I came up with decent strategies for making the FoxPro tables
> work well with the workload that was plac
On 26/06/2010 3:36 AM, t...@exquisiteimages.com wrote:
I am in the process of moving a system that has been built around FoxPro
tables for the last 18 years into a PostgreSQL based system.
Over time I came up with decent strategies for making the FoxPro tables
work well with the workload that wa
Interesting point you made about the read to write ratio of 1 to 15.
How frequently will you be adding new entities or in the case of storing the
customers in one database table, how frequently will you be adding new
objects of a certain entity type. How many entity types do you foresee
existing? i
Kevin Grittner wrote:
A schema is a logical separation within a database. Table
client1.account is a different table from client2.account. While a
user can be limited to tables within a single schema, a user with
rights to all the tables can join between them as needed. You could
put common re
On 6/25/10 3:28 PM, Kevin Grittner wrote:
wrote:
With the PostgreSQL type tables I am not so certain how the data
is arranged within the one file. Does having the data all in one
database allow PostgreSQL to better utilize indexes and caches or
does having a number of smaller databases provide
wrote:
> With the dBase and ISAM tables I have a good idea of how to handle
> them since I have been working with them since dBASE originally
> came out.
Ah, someone with whom I can reminisce about CP/M and WordStar? :-)
> With the PostgreSQL type tables I am not so certain how the data
> i
I am in the process of moving a system that has been built around FoxPro
tables for the last 18 years into a PostgreSQL based system.
Over time I came up with decent strategies for making the FoxPro tables
work well with the workload that was placed on them, but we are getting to
the point that th
10 matches
Mail list logo
