Camilo Porto <[EMAIL PROTECTED]> writes:
> The problem I have encountered is that the sum of executor's
> duration time is, *sometimes*, bigger than the total time interval in
> which the statements had been executed!! And this makes no sense!
Umm ... why not? If you have, say, two queries execut
Hi,
I
have been doing my master degree research and I am using Postgresql
8.2.5. I would appreciate if anyone could help me, ASAP, concerning the
following question:
How can I obtain the time spent by the Postgresql EXECUTOR during a given
time interval?
I am trying to get the above info
On Fri, 26 Oct 2007, Tom Lane wrote:
The 8.3 bgwriter keeps running even during checkpoints, so it's feasible
to add such a feature now.
I wonder though whether the walwriter wouldn't be a better place for it.
I do, too, but that wasn't available until too late in the 8.3 cycle to
consider a
While fooling around with the planner performance bug reported here:
http://archives.postgresql.org/pgsql-bugs/2007-10/msg00173.php
I noticed that even after fixing the bug, 8.3 seemed to plan this
many-way join about 50% slower than 8.2 :-(. After some digging
I understand the reason: 8.3 will al
Tom,
> This seems pretty entirely orthogonal to the commit-fest proposal.
> I see no reason to think that snapshots taken at those times would
> be any better than any other nightly snapshot, nor any reason
> to memorialize them in an archive.
I can see that. And it would be pretty hard to keep
Greg Smith <[EMAIL PROTECTED]> writes:
> The 8.3 bgwriter keeps running even during checkpoints, so it's feasible
> to add such a feature now.
I wonder though whether the walwriter wouldn't be a better place for it.
regards, tom lane
---(end of br
Jeff Davis <[EMAIL PROTECTED]> writes:
> I would think if the current location does not end in all zeros, you
> should expect a new WAL segment to be archived soon. Although this
> assumes that an idle database would not advance that location at all,
> and I'm still trying to understand Tom's propo
On Fri, 2007-10-26 at 18:06 -0500, Kevin Grittner wrote:
> Hmmm... We would actually prefer to get the WAL file at the
> specified interval. We have software to ensure that the warm
> standby instances are not getting stale, and that's pretty simple
> with the current behavior. We don't have a b
On Fri, 26 Oct 2007, Andrew Sullivan wrote:
Sort of a filthy hack, but what about always having an _extra_
segment around? The bgwriter could do that, no?
Now it could. The bgwriter in <=8.2 stops executing when there's a
checkpoint going on, and needing more WAL segments because a checkpoi
On Fri, 2007-10-26 at 18:47 -0400, Tom Lane wrote:
> Jeff Davis <[EMAIL PROTECTED]> writes:
> > What's happening is that you have a checkpoint_timeout of 5 minutes, and
> > that checkpoint must write a checkpoint record in the WAL, prompting the
> > archiving.
>
> > If you want it to happen less f
Jeff Davis <[EMAIL PROTECTED]> writes:
> Keep in mind that even in the current system, your configuration is
> variable based on the checkpoint_timeout setting.
Yeah, and he has to keep this less than archive_timeout in order for
it to work the way he wants, which is probably not good for performa
On Fri, 2007-10-26 at 18:06 -0500, Kevin Grittner wrote:
> >>> On Fri, Oct 26, 2007 at 5:47 PM, in message <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > And after
> > each archive_timeout, we test to see if we need to flush the current WAL
> > segment out to the archive; whic
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> On Fri, Oct 26, 2007 at 5:47 PM, in message <[EMAIL PROTECTED]>,
> Tom Lane <[EMAIL PROTECTED]> wrote:
>> And after
>> each archive_timeout, we test to see if we need to flush the current WAL
>> segment out to the archive; which is determined by whet
>>> On Fri, Oct 26, 2007 at 5:47 PM, in message <[EMAIL PROTECTED]>,
Tom Lane <[EMAIL PROTECTED]> wrote:
> And after
> each archive_timeout, we test to see if we need to flush the current WAL
> segment out to the archive; which is determined by whether the write
> pointer is currently exactly a
Jeff Davis <[EMAIL PROTECTED]> writes:
> What's happening is that you have a checkpoint_timeout of 5 minutes, and
> that checkpoint must write a checkpoint record in the WAL, prompting the
> archiving.
> If you want it to happen less frequently, it's often safe to have
> checkpoint timeout set to
On Fri, Oct 26, 2007 at 08:34:49AM -0400, Tom Lane wrote:
> we only check for the case once per checkpoint and we don't create a
> segment unless there's very little space left.
Sort of a filthy hack, but what about always having an _extra_
segment around? The bgwriter could do that, no?
A
--
Joshua D. Drake wrote:
> On Fri, 26 Oct 2007 21:58:03 +0100
> Dave Page <[EMAIL PROTECTED]> wrote:
>
>> Magnus Hagander wrote:
>>> I'm leaning towards applying the patch now, and hoping for 2b to
>>> happen.
>> I think we should live with the mingw BF breakage for a day or two.
>> The patch is cle
I changed CLOG Buffers to 16
Running the test again:
# ./read.d
dtrace: script './read.d' matched 2 probes
CPU IDFUNCTION:NAME
0 1027 :tick-5sec
/export/home0/igen/pgdata/pg_clog/0024
-27530282192961
/export/hom
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Attached is an updated version of the patch, currently being tested by
>> both me and Dave. If it passes our tests, I'll apply this so it gets
>> included for broader testing in beta2.
>
> One question: what's this about?
>
>> + #
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Attached is an updated version of the patch, currently being tested by
> both me and Dave. If it passes our tests, I'll apply this so it gets
> included for broader testing in beta2.
One question: what's this about?
> + #define _WIN32_WINNT 0x0500
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Magnus Hagander wrote:
>>> I'm leaning towards applying the patch now, and hoping for 2b to happen.
>
>> I think we should live with the mingw BF breakage for a day or two. The
>> patch is clearly an important improvement, but it should be
Dave Page <[EMAIL PROTECTED]> writes:
> Magnus Hagander wrote:
>> I'm leaning towards applying the patch now, and hoping for 2b to happen.
> I think we should live with the mingw BF breakage for a day or two. The
> patch is clearly an important improvement, but it should be as widely
> tested as p
On Fri, 26 Oct 2007 21:58:03 +0100
Dave Page <[EMAIL PROTECTED]> wrote:
> Magnus Hagander wrote:
> > I'm leaning towards applying the patch now, and hoping for 2b to
> > happen.
>
> I think we should live with the mingw BF breakage for a day or two.
> The patch is clearly an important improvement
Magnus Hagander wrote:
> I'm leaning towards applying the patch now, and hoping for 2b to happen.
I think we should live with the mingw BF breakage for a day or two. The
patch is clearly an important improvement, but it should be as widely
tested as possible.
/D
---(end o
Magnus Hagander wrote:
> Dave Page wrote:
>> Magnus Hagander wrote:
>>> Right. You need to look at VM size in *process explorer*. VM size in
>>> task manager has nothing to do with VM size, it's the private bytes :-S
>>> And there is no way to see that info from task manager, I think. PE is
>>> you
Dave Page wrote:
> Magnus Hagander wrote:
>> Right. You need to look at VM size in *process explorer*. VM size in
>> task manager has nothing to do with VM size, it's the private bytes :-S
>> And there is no way to see that info from task manager, I think. PE is
>> your friend.
>>
>>
>> Anyway. Oth
Magnus Hagander wrote:
> Right. You need to look at VM size in *process explorer*. VM size in
> task manager has nothing to do with VM size, it's the private bytes :-S
> And there is no way to see that info from task manager, I think. PE is
> your friend.
>
>
> Anyway. Other than a refresher on t
Dave Page wrote:
> Magnus Hagander wrote:
>> VM size in taskmgr should show that I think, and should show a much
>> smaller footprint now..
>
> With patch -4,492K
> Without patch: 28,224K
>
> Thats with 3 x 100 pgbench connections.
That's nice!
But. That can't be address space usage, it ha
Magnus Hagander wrote:
> VM size in taskmgr should show that I think, and should show a much
> smaller footprint now..
With patch -4,492K
Without patch: 28,224K
Thats with 3 x 100 pgbench connections.
/D
---(end of broadcast)---
TIP 3: Have
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
> So the ratio of reads vs writes to clog files is pretty huge..
It looks to me that the issue is simply one of not having quite enough
CLOG buffers. Your first run shows 8 different pages being fetched and
the second shows 10. Bearing in mind that w
On Oct 26, 2007, at 12:56 AM, Magnus Hagander wrote:
On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote:
On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
What you're asking for is basically a krb_match_realm parameter,
or do I under
Also to give perspective on the equivalent writes on CLOG
I used the following script which runs for 10 sec to track all writes to
the clog directory and here is what it came up with... (This is with 500
users running)
# cat write.d
#!/usr/sbin/dtrace -s
syscall::write:entry
/execname=="postg
> > Taking this one to -hackers once and for all now...
> >
> > Can you try the attached patch? See how many backends you can get up to.
>
> Regression tests run just fine, and I've run multiple pgbench runs with
> 3 and 4 sessions of 100 connections each*, with pgAdmin monitoring
> things at the
Magnus Hagander wrote:
> Taking this one to -hackers once and for all now...
>
> Can you try the attached patch? See how many backends you can get up to.
Regression tests run just fine, and I've run multiple pgbench runs with
3 and 4 sessions of 100 connections each*, with pgAdmin monitoring
thin
Tom,
Here is what I did:
I started aggregating all read information:
First I also had added group by pid(arg0,arg1, pid) and the counts
were all coming as 1
Then I just grouped by filename and location (arg0,arg1 of reads) and
the counts came back as
# cat read.d
#!/usr/sbin/dtrace -s
Forget this one, just missing the WITH HOLD option...
Must teach myself a bit more before sending further mails.
Seb
Sebastien FLAESCH wrote:
Ok...
Tested with 8.2.3:
Actually you can't DECLARE a cursor outside a transaction:
test1=> declare c1 cursor for select * from dbit2;
ERROR: DECLARE
Ok...
Tested with 8.2.3:
Actually you can't DECLARE a cursor outside a transaction:
test1=> declare c1 cursor for select * from dbit2;
ERROR: DECLARE CURSOR may only be used in transaction blocks
That's the main reason why we don't use DECLARE CURSOR...
I understand we could use DECLARE CURS
I agree with Tom.. somehow I think increasing NUM_CLOG_BUFFERS is just
avoiding the symptom to a later value.. I promise to look more into it
before making any recommendations to increase NUM_CLOG_BUFFERs.
Because though "iGen" showed improvements in that area by increasing
num_clog_buffer
Tom Lane wrote:
Sebastien FLAESCH <[EMAIL PROTECTED]> writes:
Does a simple PQPrepare() with a SELECT statement not create a cursor on
the server side?
No. A prepared statement is just a query plan, not a query-in-progress.
Yes of course, I meant PQprepare() + PQexecPrepared() ...
The Bi
The problem I saw was first highlighted by EAStress runs with PostgreSQL
on Solaris with 120-150 users. I just replicated that via my smaller
internal benchmark that we use here to recreate that problem.
EAStress should be just fine to highlight it.. Just put pg_clog on
O_DIRECT or something s
Hi George,
I have seen the 4M/sec problem first actually during an EAStress type
run with only 150 connections.
I will try to do more testing today that Tom has requested.
Regards,
Jignesh
Gregory Stark wrote:
"Jignesh K. Shah" <[EMAIL PROTECTED]> writes:
CLOG data is not cached in a
Sebastien FLAESCH <[EMAIL PROTECTED]> writes:
> Does a simple PQPrepare() with a SELECT statement not create a cursor on
> the server side?
No. A prepared statement is just a query plan, not a query-in-progress.
The Bind/Execute messages sent by PQexecPrepared create something akin
to a cursor,
On 10/26/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> This ties into a loose end we didn't get to yet: being more aggressive
> about creating future WAL segments. ISTM there is no good reason for
> clients ever to have to wait for WAL segment creation --- the bgwriter,
> or possibly the walwriter, ou
On 10/26/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > On 10/26/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> >> Gokulakannan Somasundaram wrote:
> >>> As far as Load Test is concerned, i have tried to provide all the
> >> relevant
> >>> details. P
Thanks Heikki for this quick answer.
Actually we do the following lipq calls:
- PQPrepare(... "SELECT ... FROM ... FOR UPDATE" ... )
- PQexecPrepared(...)
- PQntuples(...) / PQgetvalue(...)
i.e. we don't use the DECLARE CURSOR instruction, we just prepare/execute
the plain SELECT statement (wit
Greg Smith <[EMAIL PROTECTED]> writes:
> On Fri, 26 Oct 2007, ITAGAKI Takahiro wrote:
>> Mixed usage of buffered and direct i/o is legal, but enforces complexity
>> to kernels. If we simplify it, things would be more relaxed. For
>> example, dropping zero-filling and only use direct i/o. Is it po
On Fri, Oct 26, 2007 at 05:25:39AM -0700, Trevor Talbot wrote:
> On 10/26/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
>
> > Can you try the attached patch? See how many backends you can get up to.
> >
> > This patch changes from using a single thread for each backend started to
> > using the bu
On 10/26/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Can you try the attached patch? See how many backends you can get up to.
>
> This patch changes from using a single thread for each backend started to
> using the builtin threadpool functionality. It also replaces the pid/handle
> arrays wi
On Mon, Oct 22, 2007 at 01:19:24PM -0700, Trevor Talbot wrote:
> On 10/22/07, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> > Trevor Talbot wrote:
>
> > > I'd probably take the approach of combining win32_waitpid() and
> > > threads. You'd end up with 1 thread per 64 backends; when something
> > >
Gokulakannan Somasundaram wrote:
> On 10/26/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>> Gokulakannan Somasundaram wrote:
>>> As far as Load Test is concerned, i have tried to provide all the
>> relevant
>>> details. Please inform me, if i have left any.
>> Thanks!
>>
>> How large were the
On 10/26/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
>
> Gokulakannan Somasundaram wrote:
> > As far as Load Test is concerned, i have tried to provide all the
> relevant
> > details. Please inform me, if i have left any.
>
> Thanks!
>
> How large were the tables?
It is in the Performance t
Sebastien FLAESCH wrote:
> Just looked at the new features of 8.3 and realized that positioned
> updates/deletes is now possible with this new release...
>
> We would use that if we could define the cursor name with a libpq function.
I don't understand. When you open a cursor with DECLARE CURSOR,
Gokulakannan Somasundaram wrote:
> As far as Load Test is concerned, i have tried to provide all the relevant
> details. Please inform me, if i have left any.
Thanks!
How large were the tables?
Did you run all the queries concurrently? At this point, I think it'd be
better to run them separately
Hi hackers,
Just looked at the new features of 8.3 and realized that positioned
updates/deletes is now possible with this new release...
We would use that if we could define the cursor name with a libpq function.
Something similar to ODBC's SQLSetCursorName() function...
For now we must use OI
On Thu, Oct 25, 2007 at 12:31:30PM -0400, Andrew Dunstan wrote:
>
> From time to time people have raised the idea of a CPAN-like mechanism
> for downloading, building and installing extensions and the like (types,
> functions, sample dbs, anything not requiring Postgres itself to be
> rebuilt),
Am Donnerstag, 25. Oktober 2007 schrieb Andrew Dunstan:
> From time to time people have raised the idea of a CPAN-like mechanism
> for downloading, building and installing extensions and the like (types,
> functions, sample dbs, anything not requiring Postgres itself to be
> rebuilt), and I have b
On 10/25/07, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> From time to time people have raised the idea of a CPAN-like mechanism
> for downloading, building and installing extensions and the like (types,
> functions, sample dbs, anything not requiring Postgres itself to be
> rebuilt), and I have
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Actually, 32 made a significant difference as I recall ... do you still have
> the figures for that, Jignesh?
Well it made a difference but it didn't remove the bottleneck, it just moved
it. IIRC under that benchmark Jignesh was able to run with x sess
On Thu, Oct 25, 2007 at 05:39:37PM -0700, Henry B. Hotz wrote:
>
> On Oct 25, 2007, at 3:27 PM, Stephen Frost wrote:
>
> >* Henry B. Hotz ([EMAIL PROTECTED]) wrote:
> >What you're asking for is basically a krb_match_realm parameter, or
> >do I
> >understand you wrong?
>
> I'm asking for name mat
59 matches
Mail list logo
