On 12/14/06, Tom Lane <[EMAIL PROTECTED]> wrote:
Evgeny Gridasov <[EMAIL PROTECTED]> writes:
> This is a Linux Debian 3.1 ontop of 2x XEON 3.4 Ghz.
> PostgreSQL is 8.2 checked out from CVS REL8_2_STABLE yesterday.
> I'm running the same Postgres on another machine,
> with Debian Etch and have the
On 1/8/06, Ron <[EMAIL PROTECTED]> wrote:
Among the other tricks having lots of RAM allows:If some of your tables are Read Only or VERY rarely written to, youcan preload them at boot time and make them RAM resident using the/etc/tmpfs trick.
What is the /etc/tmpfs trick?
-K
On 1/4/06, Steve Eckmann <[EMAIL PROTECTED]> wrote:
Thanks, Steinar. I don't think we would really run with fsync off, but
I need to document the performance tradeoffs. You're right that my
explanation was confusing; probably because I'm confused about how to
use COPY! I could batch multiple INSERT
On Fri, 2005-11-11 at 18:02 -0500, Tom Lane wrote:
> > There very well could be a pattern in the data which could affect
> > things, however, I'm not sure how to identify it in 100K rows out of
> > 100M.
>
> I conjecture that the problem areas represent places where the key
> sequence is significa
On Thu, 2005-11-10 at 19:13 -0500, Tom Lane wrote:
> Kelly Burkhart <[EMAIL PROTECTED]> writes:
> > ... A graph showing the performance
> > characteristics is here:
>
> > <http://kkcsm.net/pgcpy.jpg>
>
> I hadn't looked at this chart till jus
Second try... no attachment this time.
I've finally gotten around to profiling the back end. Here is a more
precise description of what I'm doing:
I am copying data into two tables, order_main and order_transition
(table defs at the end of this post). The order_transition table has
roughly doub
On Tue, 2005-11-01 at 10:37 -0500, Ron Peacetree wrote:
> I'm surprised that no one seems to have yet suggested the following
> simple experiment:
>
> Increase the RAM 4GB -> 8GB, tune for best performance, and
> repeat your 100M row insert experiment.
>
> Does overall insert performance change?
On Mon, 2005-10-31 at 16:18 -0500, Tom Lane wrote:
> Kelly Burkhart <[EMAIL PROTECTED]> writes:
> > Ha! So I'm creating an index 98% full of nulls! Looks like this is
> > easily fixed with partial indexes.
>
> Still, though, it's not immediately clear why
On Mon, 2005-10-31 at 15:30 -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I've been trying to figure out whether null values are indexed or not from
> > the documentation. I was under the impression, that null values are not
> > stored in the index.
>
> You're mistaken, at least with rega
On Mon, 2005-10-31 at 12:32 -0500, Merlin Moncure wrote:
> well, can you defer index generation until after loading the set (or use
> COPY?)
I cannot defer index generation.
We are using the copy API. Copying 1 rows in a batch.
>
> if that index is causing the problem, you may want to cons
Greetings,
We are running some performance tests in which we are attempting to
insert about 100,000,000 rows in a database at a sustained rate. About
50M rows in, our performance drops dramatically.
This test is with data that we believe to be close to what we will
encounter in production. Howe
I am working on a system which will be heavily dependent on functions
(some SQL, some PL/pgSQL). I am worried about the backend caching query
execution plans for long running connections.
Given:
- Processes which are connected to the database for long periods of time
(transactions are always shor
On Thu, 2005-08-25 at 11:16 -0400, Ron wrote:
> ># - Settings -
> >
> >fsync = false # turns forced synchronization on or off
> >#wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, open_sync, or
>
> I hope
13 matches
Mail list logo
