On Wed, 2005-08-24 at 01:56 -0400, Tom Lane wrote:
> "Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> > On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
> >> Dont forget that already in postgres, you have a process per connection,
> >> and
> >> all the processes take care of their own I/O.
>
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
>> Dont forget that already in postgres, you have a process per connection, and
>> all the processes take care of their own I/O.
> That's the problem. Instead you want 1 or 4 or 10 i/o slaves
>
On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote:
> As for the async IO, sure you might think 'oh async IO would be so cool!!'
> and I did, once, too. But then I sat down and _thought_ about it, and
> decided well, no, actually, theres _very_ few areas it could actually help,
> and in most cas
On Wed, 24 Aug 2005, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > A filesystem could, in theory, help us by providing an API which allows us
> > to tell the file system either: the way we'd like it to read ahead, the
> > fact that we don't want it to read ahead or the way we'd li
> Unfortunately I'm really afraid that this conversation is about trees
> when the forest is the problem. PostgreSQL doesn't even have an async
> reader, which is the sort of thing that could double or triple its
> performance. You're talking about block sizes and such, but the kinds
> of improve
"Jeffrey W. Baker" <[EMAIL PROTECTED]> writes:
> To get decent I/O you need 1MB fundamental units all the way down the
> stack.
It would also be a good idea to have an application that isn't likely
to change a single bit in a 1MB range and then expect you to record
that change. This pretty much l
Gavin Sherry <[EMAIL PROTECTED]> writes:
> A filesystem could, in theory, help us by providing an API which allows us
> to tell the file system either: the way we'd like it to read ahead, the
> fact that we don't want it to read ahead or the way we'd like it to cache
> (or not cache) data. The thin
On Tue, 2005-08-23 at 19:31 -0700, Josh Berkus wrote:
> Steve,
>
> > I would assume that dbt2 with STP helps minimize the amount of hours
> > someone has to invest to determine performance gains with configurable
> > options?
>
> Actually, these I/O operation issues show up mainly with DW workloa
On Wed, 24 Aug 2005, PFC wrote:
>
> > Josh Berkus has already mentioned this as conventional wisdom as written
> > by Oracle. This may also be legacy wisdom. Oracle/Sybase/etc has been
> > around for a long time; it was probably a clear performance win way back
> > when. Nowadays with how far open
Josh Berkus wrote:
Steve,
I would assume that dbt2 with STP helps minimize the amount of hours
someone has to invest to determine performance gains with configurable
options?
Actually, these I/O operation issues show up mainly with DW workloads, so the
STP isn't much use there. If
Steve,
> I would assume that dbt2 with STP helps minimize the amount of hours
> someone has to invest to determine performance gains with configurable
> options?
Actually, these I/O operation issues show up mainly with DW workloads, so the
STP isn't much use there. If I can ever get some of th
Hi Jim,
| How many of these things are currently easy to change with a recompile?
| I should be able to start testing some of these ideas in the near
| future, if they only require minor code or configure changes.
The following
* Data File Size 1GB
* WAL File Size of 16MB
* Block Size of 8K
PFC,
> Now, Hans Reiser has expressed interest on the ReiserFS list in
> tweaking his Reiser4 especially for Postgres. In his own words, he wants
> a "Killer app for reiser4". Reiser4 will offser transactional semantics via
> a special reiser4 syscall, so it might be possible, with a min
On Tue, 2005-08-23 at 19:12 -0400, Michael Stone wrote:
> On Tue, Aug 23, 2005 at 05:29:01PM -0400, Jignesh Shah wrote:
> >Actually some of that readaheads,etc the OS does already if it does
> >some sort of throttling/clubbing of reads/writes.
>
> Note that I specified the fully cached case--eve
Chris,
Unless I am wrong, you're making the assumpting the amount of time spent
and ROI is known. Maybe those who've been down this path know how to get
that additional 2-4% in 30 minutes or less?
While each person and business' performance gains (or not) could vary,
someone spending the 50-100h
On Tue, Aug 23, 2005 at 06:09:09PM -0400, Chris Browne wrote:
> [EMAIL PROTECTED] (Jignesh Shah) writes:
> >> Does that include increasing the size of read/write blocks? I've
> >> noticedthat with a large enough table it takes a while to do a
> >> sequential scan, even if it's cached; I wonder if t
Josh Berkus has already mentioned this as conventional wisdom as written
by Oracle. This may also be legacy wisdom. Oracle/Sybase/etc has been
around for a long time; it was probably a clear performance win way back
when. Nowadays with how far open-source OS's have advanced, I'd take it
w
On Tue, Aug 23, 2005 at 06:09:09PM -0400, Chris Browne wrote:
What we have been finding, as RAID controllers get smarter, is that it
is getting increasingly futile to try to attach knobs to 'disk stuff;'
it is *way* more effective to add a few more spindles to an array than
it is to fiddle with w
On Tue, Aug 23, 2005 at 05:29:01PM -0400, Jignesh Shah wrote:
Actually some of that readaheads,etc the OS does already if it does
some sort of throttling/clubbing of reads/writes.
Note that I specified the fully cached case--even with the workload in
RAM the system still has to process a heck
[EMAIL PROTECTED] (Jignesh Shah) writes:
>> Does that include increasing the size of read/write blocks? I've
>> noticedthat with a large enough table it takes a while to do a
>> sequential scan, even if it's cached; I wonder if the fact that it
>> takes a million read(2) calls to get through an 8G
Donald Courtney wrote:
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 drop. I am not alone in having the *expectation*
What's your basis for believing this is the case? Why would PostgreSQL's
depend
> Does that include increasing the size of read/write blocks? I've
> noticedthat with a large enough table it takes a while to do a
> sequential scan,
> even if it's cached; I wonder if the fact that it takes a million
> read(2) calls to get through an 8G table is part of that.
>
Actually some
[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
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 increasing the size of read/write blocks? I've noticed
that w
On Tue, Aug 23, 2005 at 02:41:39PM -0400, Donald Courtney wrote:
> 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
>
Donald,
> 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 drop.
Since when? Barring the context switch bug, you're not going
Donald Courtney <[EMAIL PROTECTED]> writes:
> I am not alone in having the *expectation* that a database should have
> some cache size parameter and the option to skip the file system. If
> I use oracle, sybase, mysql and maxdb they all have the ability to
> size a data cache and move to 64 bits.
Tom,
> > Would it be best to attempt to rewrite it for IN?
> > Or, should we try to tie it in with a join?
>
> Couldn't say without a deeper understanding of what you're trying to
> accomplish.
Here are the results of each SQL rewrite.
The first pass, I rewrote it as c.id IN ():
-
LOG: dur
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 drop. I am not alone in having the *expectation*
t
On Tue, Aug 23, 2005 at 10:10:45 -0700,
gokulnathbabu manoharan <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I like to know the caching policies of Postgresql.
> What parameter in the postgresql.conf affects the
> cache size used by the Postgresql? As far as I have
> searched my knowledge of the p
John,
> So I'm guessing that with 8.1 there would be 2 sweet spots. Low
> shared_buffers (<= 10k), and really high shared buffers (like all of
> available ram).
> But because postgres has been tuned for the former I would stick with it
> (I don't think shared_buffers can go >2GB, but that might ju
On Tue, 23 Aug 2005 10:10:45 -0700 (PDT)
gokulnathbabu manoharan <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I like to know the caching policies of Postgresql.
> What parameter in the postgresql.conf affects the
> cache size used by the Postgresql? As far as I have
> searched my knowledge of the p
gokulnathbabu manoharan wrote:
> Hi all,
>
> I like to know the caching policies of Postgresql.
> What parameter in the postgresql.conf affects the
> cache size used by the Postgresql? As far as I have
> searched my knowledge of the parameters are
In general, you don't. The OS handles caching bas
Hi all,
I like to know the caching policies of Postgresql.
What parameter in the postgresql.conf affects the
cache size used by the Postgresql? As far as I have
searched my knowledge of the parameters are
1. shared_buffers - Sets the limit on the amount of
shared memory used. If I take this is
"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
=?ISO-8859-2?Q?Sz=FBcs_G=E1bor?= <[EMAIL PROTECTED]> writes:
> [ bad query plan ]
Most of the problem is here:
> -> Index Scan using muvelet_vonalkod_ny_idopont on
> muvelet_vonalkod_ny ny (cost=0.00..1351.88 rows=24649 width=4) (actual
> time=0.161..10.735 rows=3943 loo
Dear Gurus,
System: Debian "Woody" 2.4.28
Version: PostgreSQL 7.4.8
I have a join which causes a better hash if I provide a "trivial" condition:
WHERE m.nap > '1900-01-01'::date
This is a date field with a minimum of '2005-06-21'. However, if I omit this
condition from the WHERE clause, I get a
pgbench is located in the contrib directory of any source tarball,
along with a README that serves as documentation.
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN
Jeremiah Jahn wrote:
> On Sun, 2005-08-21 at 16:13 -0400, Ron wrote:
>
>>At 10:54 AM 8/21/2005, Jeremiah Jahn wrote:
>>
...
>>So you have 2 controllers each with 2 external slots? But you are
>>currently only using 1 controller and only one external slot on that
>>controller?
>
>
> Sorry, no. I
40 matches
Mail list logo
