On Sat, 1 Nov 2003, Michael Owens wrote:
> Isn't this information (the number of matched records) available to the
> backend --- even in the case of LIMIT? All matched records still have to be
> materialized right? Therefore the record count should be available and could
> therefore be available t
I should perhaps dig a little more on this one, but per the C API docs I don't
think what I am asking for is available. This somewhat relates to count().
Is there a reasonable way that information regarding the number of matched
records could be passed back to the client --- even in the case of
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
>
We might branch CVS for 7.4 STABLE when we release RC1, so we might be
able to start development on 7.5 soon.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Chr
I am heading to Frankfurt for the International PHP Conference in an
hour. I will return on Thursday afternoon, EST. Looks like we might
have an RC1 early this week, but the docs aren't frozen until final
release, so I will return to the release notes and ports list when I
return. I am not sure
Stephen wrote:
I tried the Tom Lane's patch on PostgreSQL 7.4-BETA-5 and it works
fantastically! Running a few short tests show a significant improvement in
responsiveness on my RedHat 9 Linux 2.4-20-8 (IDE 120GB 7200RPM UDMA5).
I am currently looking at implementing ARC as a replacement strategy.
Tom Lane wrote:
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.
Wrong. From the opengroup manpage:
<<
SIG_IGN - ignore signal
[
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
Michael Mauger writes:
> Emacs is not a Cygwin (Un*x emulation on Windows) executable (like psql
> is)
Why don't you use the native Windows version of psql?
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9'
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
Tom Lane wrote:
A bigger objection is that we couldn't get libssl to use it (AFAIK).
The flag really needs to be settable on the socket (eg, via fcntl),
not per-send.
It's a per-send flag, it's not possible to force it on with a fcntl :-(
What about an option to skip the sigaction calls for apps
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
"Stephen" <[EMAIL PROTECTED]> writes:
> also as there are less processes waiting to complete. I find a value of 1ms
> to 5ms is quite good and will keep system responsive. Going from 10ms to 1ms
> didn't seem to reduce the total vacuum time by much and I'm not sure why.
On most Unixen, the effecti
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
Michael Mauger writes:
> I'm the maintainer of sql.el in GNU Emacs. On both the Mac OS X
> and the Windows/Cygwin platform we've had reports that psql run
> under Emacs does not issue a prompt for commands.
Why can't you make the Emacs session behave like a terminal for psql?
--
Peter Eisentra
I tried the Tom Lane's patch on PostgreSQL 7.4-BETA-5 and it works
fantastically! Running a few short tests show a significant improvement in
responsiveness on my RedHat 9 Linux 2.4-20-8 (IDE 120GB 7200RPM UDMA5).
I didn't feel any noticeable delay when vacuum_page_delay is set to 5ms, 10
ms. Vac
>I'd rather see us implement a buffer replacement policy that considers
>both frequency + recency (unlike LRU, which considers only recency).
>Ideally, that would work "automagically". I'm hoping to get a chance to
>implement ARC[1] during the 7.5 cycle.
Actually i've already done some work back i
I included some text about the information schema in
this issue of general bits. I also did some documentation
of comparison of the changes in the postgresql.conf.
Anyone who wants to grab parts of those items in that
issue has my permission. I don't have time to re-edit
for the release note for
I'm the maintainer of sql.el in GNU Emacs. On both the Mac OS X
and the Windows/Cygwin platform we've had reports that psql run
under Emacs does not issue a prompt for commands.
I did a little research and it appears that the cause is that
pset.notty is being set to false because stdin/stdou
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 <[EMAIL PROTECTED]> writes:
> However, if a test fails, it is quite likely that a whitespace-sensitive
> diff will produce many lines of uninteresting diff, because of psql's habit
> of justifying column output
Perhaps the regression tests should just do \pset format unaligned ?
--
gr
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
In any case, can't 7.3 pg_dump use the 7.4 libpq?
If not then the major version should be bumped.
My point being that I would like to actually preserve my cluster
settings and stuff when dumping...
So it's pg_dump, not libpq, that's important to me.
Chris
---(end of bro
I ran into this too. Patched the code with Tom's change and it works fine.
Thanks again Tom!
Richard Schilling
On 2003.07.17 11:04 Hannu Krosing wrote:
> Tom Lane kirjutas N, 17.07.2003 kell 19:49:
> > Ugh. The reason we hadn't seen this happen in the field was that it is
> > a bug I introduce
34 matches
Mail list logo
