Mark Wong <[EMAIL PROTECTED]> writes:
> I've changed all the numerics to integers and reals, where it was appropriate
> to maintain the precision specificed in the TPC-C spec.
> ...
> Looks like I see about an 8% improvement in the metric with this instance. A
> definite decrease in user time in t
On Sun, Nov 02, 2003 at 07:25:38AM -0500, Rod Taylor wrote:
> On Sat, 2003-11-01 at 20:58, Mark Wong wrote:
> > I don't remember making a conscious decision between the number and integer
> > database type. Is that a significant oversight on my part?
>
> Numerics do exact math with support for ar
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
For multithreaded apps, this is not possible: sigaction is per process.
Thus the calling application must handle the SIGPIPE signals for libpq -
either by blocking or ignoring them. We are still discussing the exact
API. Probably a gl
Manfred Spraul <[EMAIL PROTECTED]> writes:
> For multithreaded apps, this is not possible: sigaction is per process.
> Thus the calling application must handle the SIGPIPE signals for libpq -
> either by blocking or ignoring them. We are still discussing the exact
> API. Probably a global state t
[EMAIL PROTECTED] wrote:
On 1 Nov, Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
signal handlers are a process property, not a thread property - that
code is broken for multi-threaded apps.
Yeah, that's been mentioned before, but I don't see any way around it.
What we
On 1 Nov, Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
>> signal handlers are a process property, not a thread property - that
>> code is broken for multi-threaded apps.
>
> Yeah, that's been mentioned before, but I don't see any way around it.
> What we really want is to turn of
On Sat, 2003-11-01 at 20:58, Mark Wong wrote:
> I don't remember making a conscious decision between the number and integer
> database type. Is that a significant oversight on my part?
Numerics do exact math with support for arbitrary numbers. Unlike
Oracle, PostgreSQL does not retype NUMBER to
Mark Wong wrote:
On Sat, Nov 01, 2003 at 10:29:34PM +0100, Manfred Spraul wrote:
Mark Wong wrote:
Yeah, my dbt2 applications are multithreaded.
Do you need SIGPIPE delivery in your app? If no, could you try what
happens if you apply the attached patch to postgres, and perform the
On Sat, Nov 01, 2003 at 10:29:34PM +0100, Manfred Spraul wrote:
> Mark Wong wrote:
>
> >Yeah, my dbt2 applications are multithreaded.
> >
> >
> Do you need SIGPIPE delivery in your app? If no, could you try what
> happens if you apply the attached patch to postgres, and perform the
> signal
Numerics are a LOT slower than reals. Integers are faster than anything
I guess.
Chris
Mark Wong wrote:
I don't remember making a conscious decision between the number and integer
database type. Is that a significant oversight on my part?
On Fri, Oct 31, 2003 at 08:04:34PM -0500, Rod Taylor w
On Sat, Nov 01, 2003 at 02:37:21PM +0100, Manfred Spraul wrote:
> Tom Lane wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >
> >>7.4beta5 offers more throughput. One significant difference I see is in
> >>the oprofile for the database. For the additional 7% increase in the
> >>metric, there are ab
I don't remember making a conscious decision between the number and integer
database type. Is that a significant oversight on my part?
On Fri, Oct 31, 2003 at 08:04:34PM -0500, Rod Taylor wrote:
> Excellent.
>
> I just noticed that most of the numbers in the system are given the
> numeric data
On Friday 31 October 2003 19:18, [EMAIL PROTECTED] wrote:
> These are the only database parameters I've explicitly set for each one,
> any other differences will be differences in default values:
> - shared_buffers = 4
> - tcpip_socket = true
> - checkpoint_segments = 200
>
Manfred Spraul <[EMAIL PROTECTED]> writes:
> What about an option to skip the sigaction calls for apps that can
> handle SIGPIPE?
If the app is ignoring SIGPIPE globally, then our calls will have no
effect anyway. I don't see that this proposal adds any security.
regards
Mark Wong wrote:
Yeah, my dbt2 applications are multithreaded.
Do you need SIGPIPE delivery in your app? If no, could you try what
happens if you apply the attached patch to postgres, and perform the
signal(SIGPIPE, SIG_IGN);
once in your dbt2 app?
--
Manfred
--- pgsql.orig/src/interfac
On Sat, Nov 01, 2003 at 07:27:01PM +0100, Manfred Spraul wrote:
> Tom Lane wrote:
>
> >Manfred Spraul <[EMAIL PROTECTED]> writes:
> >
> >
> >>Is that really necessary?
> >>
> >>
> >
> >Unfortunately, yes. libpq can't change the global setting of SIGPIPE
> >without breaking the surrounding a
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What we really want is to turn off SIGPIPE delivery on our socket
>> (only), but AFAIK there is no API to do that.
>>
> Linux has as MSG_NOSIGNAL flag for send(), but that seems to be Linux
> specific.
Hmm ... a Linux-specific solut
On Sat, Nov 01, 2003 at 02:37:21PM +0100, Manfred Spraul wrote:
> Tom Lane wrote:
>
> >[EMAIL PROTECTED] writes:
> >
> >
> >>7.4beta5 offers more throughput. One significant difference I see is in
> >>the oprofile for the database. For the additional 7% increase in the
> >>metric, there are ab
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
signal handlers are a process property, not a thread property - that
code is broken for multi-threaded apps.
Yeah, that's been mentioned before, but I don't see any way around it.
Do not handle SIGPIPE on multithreaded apps, and
Manfred Spraul <[EMAIL PROTECTED]> writes:
> signal handlers are a process property, not a thread property - that
> code is broken for multi-threaded apps.
Yeah, that's been mentioned before, but I don't see any way around it.
What we really want is to turn off SIGPIPE delivery on our socket
(onl
Tom Lane wrote:
Manfred Spraul <[EMAIL PROTECTED]> writes:
Is that really necessary?
Unfortunately, yes. libpq can't change the global setting of SIGPIPE
without breaking the surrounding application, but we don't want to crash
the app if the server connection has disappeared, either. So
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Is that really necessary?
Unfortunately, yes. libpq can't change the global setting of SIGPIPE
without breaking the surrounding application, but we don't want to crash
the app if the server connection has disappeared, either. So we have to
set the SIG
I've straced
$ pgbench -c 5 -s 6 -t 1000
total 157k syscalls, 70k of them are rt_sigaction(SIGPIPE):
1754 poll([{fd=3, events=POLLOUT|POLLERR, revents=POLLOUT}], 1, -1) = 1
1754 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
1754 send(3, "\0\0\0%\0\3\0\0user\0postgres\0database\0t"..., 37,
Tom Lane wrote:
[EMAIL PROTECTED] writes:
7.4beta5 offers more throughput. One significant difference I see is in
the oprofile for the database. For the additional 7% increase in the
metric, there are about 32% less ticks in SearchCatCache.
Hmm. I have been profiling PG for some years n
[EMAIL PROTECTED] wrote:
Results from 7.4beta5
http://developer.osdl.org/markw/dbt2-pgsql/188/
- metric 1446.01
CPU: P4 / Xeon with 2 hyper-threads, speed 1497.51 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a
unit mask of 0x01 (count c
[EMAIL PROTECTED] writes:
> 7.4beta5 offers more throughput. One significant difference I see is in
> the oprofile for the database. For the additional 7% increase in the
> metric, there are about 32% less ticks in SearchCatCache.
Hmm. I have been profiling PG for some years now, and I cannot r
Excellent.
I just noticed that most of the numbers in the system are given the
numeric data type. Is there any particular reason you don't use integer
(test enforced?)?
On Fri, 2003-10-31 at 19:18, [EMAIL PROTECTED] wrote:
> I thought someone might be interested in a data point I have comparing
>
I thought someone might be interested in a data point I have comparing
7.3.4 and 7.4beta5 with results from our DBT-2 workload. Keep in mind I
haven't done much tuning with either version. The following links have
references iostat, vmstat, sar, readprofile (linux kernel profile), and
oprofile (po
28 matches
Mail list logo
