Thanks, Tom for keeping on this. I was on vacation last week. Will try
the latest ASAP.
On Mon, 2005-08-22 at 20:20 -0400, Tom Lane wrote:
> I wrote:
> > I've been sniffing around that patch and not really finding any smoking
> > gun about why it would make things slower when you're not using
I wrote:
> I've been sniffing around that patch and not really finding any smoking
> gun about why it would make things slower when you're not using O_DIRECT.
While rewriting the patch to fit more naturally into xlog.c, I found a
bug that might possibly be related to your performance issue. The
i
On Sun, 2005-08-21 at 20:37 -0400, Tom Lane wrote:
> The whole thing's pretty bizarre.
I hate to sound obvious, but does the missing performance return if you
back the patch out? It seemed to have been decided on Tue, 16 Aug 2005
15:45:30 -0700 that the performance was the same before and after.
I wrote:
> Mary Edie Meredith <[EMAIL PROTECTED]> writes:
>> I have an example of runs that illustrate a performance
>> problem that occurred between installing the 7/18 and 8/1
>> development release codes.
> I dug through the CVS logs to see what had changed, and I'm afraid there
> is just one
> On Tue, 2005-08-16 at 16:07 -0700, Mark Wong wrote:
>> On Tue, 16 Aug 2005 18:53:55 -0400
>> Tom Lane <[EMAIL PROTECTED]> wrote:
>>
>> > Mary Edie Meredith <[EMAIL PROTECTED]> writes:
>> > > I'm still very concerned about what I'm seeing in the oprofile:
>> > > namely: .CreateLWLocks is the seco
On Tue, 2005-08-16 at 16:07 -0700, Mark Wong wrote:
> On Tue, 16 Aug 2005 18:53:55 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> > > I'm still very concerned about what I'm seeing in the oprofile:
> > > namely: .CreateLWLocks is the second high
On Tue, 16 Aug 2005 18:53:55 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> > I'm still very concerned about what I'm seeing in the oprofile:
> > namely: .CreateLWLocks is the second highest entry for postgres.
> > http://developer.osdl.org/maryedie/D
On Tue, 2005-08-16 at 18:53 -0400, Tom Lane wrote:
> Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> > I'm still very concerned about what I'm seeing in the oprofile:
> > namely: .CreateLWLocks is the second highest entry for postgres.
> > http://developer.osdl.org/maryedie/DBT2_PGSQL/59/oprofile
On Thu, 2005-08-11 at 22:11 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> > >> anyway), so shared_buffers should be irrelevant.
> >
> > > Uh, O_DIRECT really just enables when open_sync is used,
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> I'm still very concerned about what I'm seeing in the oprofile:
> namely: .CreateLWLocks is the second highest entry for postgres.
> http://developer.osdl.org/maryedie/DBT2_PGSQL/59/oprofile.txt
This says there's something wrong with your oprofile
On Thu, 11 Aug 2005 22:11:42 -0400 (EDT)
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> > >> anyway), so shared_buffers should be irrelevant.
> >
> > > Uh, O_DIRECT really just enables when open_sync i
Tom Lane wrote:
> Bruce Momjian writes:
> >> O_DIRECT is only being used for WAL page writes (or I sure hope so
> >> anyway), so shared_buffers should be irrelevant.
>
> > Uh, O_DIRECT really just enables when open_sync is used, and I assume
> > that is not used for writing dirty buffers during a
Bruce Momjian writes:
>> O_DIRECT is only being used for WAL page writes (or I sure hope so
>> anyway), so shared_buffers should be irrelevant.
> Uh, O_DIRECT really just enables when open_sync is used, and I assume
> that is not used for writing dirty buffers during a checkpoint.
I double-check
Andrew - Supernews wrote:
> On 2005-08-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > In light of this, may I ask whether it makes sense to compare the
> > performance of two runs with similar shared_buffer settings? With
> > O_DIRECT, I understand from this manpage that the OS is going to do
>
On 2005-08-12, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> In light of this, may I ask whether it makes sense to compare the
> performance of two runs with similar shared_buffer settings? With
> O_DIRECT, I understand from this manpage that the OS is going to do
> little or no page caching, so sha
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > In light of this, may I ask whether it makes sense to compare the
> > performance of two runs with similar shared_buffer settings? With
> > O_DIRECT, I understand from this manpage that the OS is going to do
> > little or no page cac
Tom Lane wrote:
> Most of the CVS activity in that time period had to with stuff like
> roles and the interval datatype. It's conceivable that these things
> had some marginal performance cost, but if so I'd have expected it to
> show up as extra CPU effort (more time checking permissions, say).
>
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> In light of this, may I ask whether it makes sense to compare the
> performance of two runs with similar shared_buffer settings? With
> O_DIRECT, I understand from this manpage that the OS is going to do
> little or no page caching, so shared_buffers sh
On Thu, Aug 11, 2005 at 09:02:03PM -0400, Tom Lane wrote:
> I am sure I will get some pushback if I propose reverting the O_DIRECT
> patch, so could you try to get some more-specific evidence? Like pull
> the CVS tree from just before and just after this patch and compare
> performance?
Quoth th
Mary Edie Meredith <[EMAIL PROTECTED]> writes:
> I have an example of runs that illustrate a performance
> problem that occurred between installing the 7/18 and 8/1
> development release codes.
I dug through the CVS logs to see what had changed, and I'm afraid there
is just one plausible-looking
I have an example of runs that illustrate a performance
problem that occurred between installing the 7/18 and 8/1
development release codes. I'm running on a PPC64 8-way system,
with 16GB of memory (on a 15GB virtual machine), with a DBT2
workload configured as a 16 warehouse DBT2 with 16 db
21 matches
Mail list logo
