[EMAIL PROTECTED] (Michael Stone) writes:
> On Tue, Aug 23, 2005 at 12:38:04PM -0700, Josh Berkus wrote:
>> which have a clear and measurable effect on performance and are
>> fixable without bloating the PG code. Some of these issues (COPY
>> path, context switching
>
> Does that include increasin
[EMAIL PROTECTED] (Donald Courtney) writes:
> I mean well with this comment -
> This whole issue of data caching is a troubling issue with postreSQL
> in that even if you ran postgreSQL on a 64 bit address space
> with larger number of CPUs you won't see much of a scale up
> and possibly even a dr
"tobbe" <[EMAIL PROTECTED]> writes:
> The company that I'm working for are surveying the djungle of DBMS
> since we are due to implement the next generation of our system.
>
> The companys buissnes is utilizing the DBMS to store data that are
> accessed trough the web at daytime (only SELECTs, some
[EMAIL PROTECTED] ("Jeffrey W. Baker") writes:
> I haven't tried this product, but the microbenchmarks seem truly
> slow. I think you would get a similar benefit by simply sticking a
> 1GB or 2GB DIMM -- battery-backed, of course -- in your RAID
> controller.
Well, the microbenchmarks were pretty
[EMAIL PROTECTED] (John A Meinel) writes:
> I saw a review of a relatively inexpensive RAM disk over at
> anandtech.com, the Gigabyte i-RAM
> http://www.anandtech.com/storage/showdoc.aspx?i=2480
And the review shows that it's not *all* that valuable for many of the
cases they looked at.
> Basical
[EMAIL PROTECTED] (Stuart Bishop) writes:
> I'm putting together a road map on how our systems can scale as our
> load increases. As part of this, I need to look into setting up some
> fast read only mirrors of our database. We should have more than
> enough RAM to fit everything into memory. I wou
[EMAIL PROTECTED] ("Mohan, Ross") writes:
> for time-series and "insane fast", nothing beats kdB, I believe
>
> www.kx.com
... Which is well and fine if you're prepared to require that all of
the staff that interact with data are skilled APL hackers. Skilled
enough that they're all ready to leap
[EMAIL PROTECTED] writes:
> How can i know a capacity of a pg database ?
> How many records my table can have ?
> I saw in a message that someone have 50 000 records it's possible in a table ?
> (My table have 8 string field (length 32 car)).
> Thanks for your response.
The capacity is much more l
[EMAIL PROTECTED] (Christopher Petrilli) writes:
> On 5/2/05, Tim Terlegård <[EMAIL PROTECTED]> wrote:
>> Howdy!
>>
>> I'm converting an application to be using postgresql instead of
>> oracle. There seems to be only one issue left, batch inserts in
>> postgresql seem significant slower than in o
josh@agliodbs.com (Josh Berkus) writes:
> David,
>
>> What also seems weird to me is that the control table has some unique
>> indexes created on it, but the data_upate_events table just has a unique
>> constraint. Will postgres use an index in the background to enforce
>> this constraint?
>
> If
josh@agliodbs.com (Josh Berkus) writes:
> Bill,
>
>> What about if an out-of-the-ordinary number of rows
>> were deleted (say 75% of rows in the table, as opposed
>> to normal 5%) followed by a 'VACUUM ANALYZE'? Could
>> things get out of whack because of that situation?
>
> Yes. You'd want to ru
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
>>So, my question is this: My server currently works great,
>>performance wise. I need to add fail-over capability, but I'm
>>afraid that introducing a stressful task such as replication will
>>hurt my server's performance. Is there any foundation to m
[EMAIL PROTECTED] ("Dave Held") writes:
>> -Original Message-
>> From: Tom Lane [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, March 22, 2005 3:48 PM
>> To: Greg Stark
>> Cc: Christopher Browne; pgsql-performance@postgresql.org
>> Subject: Re: [PERFORM] What about utility to calculate planner
[EMAIL PROTECTED] (Dawid Kuroczko) writes:
> ALTER TABLE foo ALTER COLUMN bar SET STATISTICS n; .
>
> I wonder what are the implications of using this statement,
> I know by using, say n=100, ANALYZE will take more time,
> pg_statistics will be bigger, planner will take longer time,
> on the ot
[EMAIL PROTECTED] (Pierre-Frédéric Caillaud) writes:
>> posix_fadvise(2) may be a candidate. Read/Write bareers another pone, as
>> well asn syncing a bunch of data in different files with a single call
>> (so that the OS can determine the best write order). I can also imagine
>> some interaction w
[EMAIL PROTECTED] (Matt Clark) writes:
>>As for "vendor support" for Opteron, that sure looks like a
>>trainwreck... If you're going through IBM, then they won't want to
>>respond to any issues if you're not running a "bog-standard" RHAS/RHES
>>release from Red Hat. And that, on Opteron, is prepo
[EMAIL PROTECTED] ("Simon Riggs") writes:
> Well, its fairly straightforward to auto-generate the UNION ALL view, and
> important as well, since it needs to be re-specified each time a new
> partition is loaded or an old one is cleared down. The main point is that
> the constant placed in front of
[EMAIL PROTECTED] (Dan Harris) writes:
> Christopher Browne wrote:
>
>>We have a couple of these at work; they're nice and fast, although the
>>process of compiling things, well, "makes me feel a little unclean."
>>
> Thanks very much for your detailed reply, Christopher. Would you mind
> elaborat
[EMAIL PROTECTED] (Neil Conway) writes:
> Christopher Browne wrote:
>> One of our sysadmins did all the "configuring OS stuff" part; I don't
>> recall offhand if there was a need to twiddle something in order to
>> get it to have great gobs of shared memory.
>
> FWIW, the section on configuring ker
[EMAIL PROTECTED] (Richard Huxton) writes:
> If you could "pin" data in the cache it would run quicker, but at the
> cost of everything else running slower.
>
> Suggested steps:
> 1. Read the configuration/tuning guide at:
>http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php
> 2. Post
[EMAIL PROTECTED] ("Anderson Boechat Lopes") writes:
> I´m new here and i´m not sure if this is the right email to
> solve my problem.
This should be OK...
> Well, i have a very large database, with vary tables and very
> registers. Every day, too many operations are perfomed in that DB,
[EMAIL PROTECTED] (James Thornton) writes:
> Back in 2001, there was a lengthy thread on the PG Hackers list about
> PG and journaling file systems
> (http://archives.postgresql.org/pgsql-hackers/2001-05/msg00017.php),
> but there was no decisive conclusion regarding what FS to use. At the
> time t
[EMAIL PROTECTED] writes:
> my data base is very slow. The machine is a processor Xeon 2GB with
> 256 MB of RAM DDR. My archive of configuration is this:
> sort_mem = 131072 # min 64, size in KB
> #vacuum_mem = 8192 # min 1024, size in KB
Change it back to 8192, or perh
101 - 123 of 123 matches
Mail list logo
