At 04:50 PM 9/29/01 -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On some operating systems, only one child at a time can accept() on the
socket. On these, you have to lock around the call to accept().
But how do you know the client wants the database you have forked? They
Bruce Momjian [EMAIL PROTECTED] writes:
How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
Umm... Apache? They use a preforking model and it works quite well for
Vadim Mikheev wrote:
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to see what other
Tom Lane wrote:
snip
I wonder whether we should retire -o. Or change it so that the
postmaster parses the given options for itself (consequently adjusting
its copies of GUC variables) instead of passing them on to backends
for parsing at backend start time.
Retiring -o would seem like a
Justin Clift [EMAIL PROTECTED] writes:
Retiring -o would seem like a good idea.
That was what I was thinking too. I can think of ways to reimplement
-o options so that they work safely ... but is it worth the trouble?
AFAICS, -o options confuse both people and machines, and have no
redeeming
I did some benchmarking with/without multibyte support using current.
(1) regression test
(2) pgbench
pgbench unfortunately seems quite irrelevant to this issue, since it
performs no textual operations whatsoever. It'd be interesting to
modify pgbench so that it updates the filler
I wrote:
The following proposal should improve performance substantially when
there is contention for a lock, but it creates no portability risks
...
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to see what other people
observe. (Tatsuo,
On Thursday 27 September 2001 04:09, you wrote:
This depends on your system. Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little
difference (and in fact a Linux process context switch is about as
fast as a Solaris thread switch on the
Vadim Mikheev [EMAIL PROTECTED] writes:
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to
The O_DIRECT flag has been added in FreeBSD 4.4 (386 Alpha) also. From
the release notes:
Kernel Changes
The O_DIRECT flag has been added to open(2) and fcntl(2). Specifying this
flag for open files will attempt to minimize the cache effects of reading
and writing.
I wonder if using
I've committed (most of?) the changes to implement a timestamp without
time zone type. To help with backward compatibility and upgrading, I've
made the *default* timestamp the one with time zone. That is, if you
want a timestamp without time zone you will have to fully specify it
verbatim. SQL99
Good summary. I agree checkpoint should look like as normal a Proc as
possible.
At the just-past OSDN database conference, Bruce and I were annoyed by
some benchmark results showing that Postgres performed poorly on an
8-way SMP machine. Based on past discussion, it seems likely that the
Well, O_DIRECT has finally made it into the Linux kernel. It lets you
open a file in such a way that reads and writes don't go to the buffer
cache but straight to the disk. Accesses must be aligned on
filesystem block boundaries.
Is there any case where PG would benefit from this? I
* Doug McNaught [EMAIL PROTECTED] wrote:
|
| Depends on what you mean. For scaling well with many connections and
| simultaneous queries, there's no reason IMHO that the current
| process-per-backend model won't do, assuming the locking issues are
| addressed.
Wouldn't a threading model allow
Chamanya wrote:
On Thursday 27 September 2001 04:09, you wrote:
This depends on your system. Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little
difference (and in fact a Linux process context switch is about as
fast as a
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
Please apply attached patch to current CVS tree.
Changes:
1. gist__int_ops is now without lossy
2. added sort
Bruce Momjian [EMAIL PROTECTED] writes:
How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
No idea but it seemed like a nice optimization if we could do it.
--
Bruce Momjian [EMAIL PROTECTED] writes:
How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
regards, tom lane
---(end
Tatsuo Ishii writes:
Has anyone successfully built docs recently? I got:
cd sgml /bin/tar -c -f ../admin.tar -T HTML.manifest *.gif *.css
/bin/tar: *.gif: Cannot stat: No such file or directory
I'll fix it.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
I've been looking at the iscachable changes you committed recently,
and I think a lot of them need to be adjusted still.
One consideration I hadn't thought of recently (though I think we did
take it into account for the 7.0 release) is that any function whose
output varies depending on the
Bruce Momjian [EMAIL PROTECTED] writes:
No scale factor, as I illustrated from the initialization command I
used. Standard buffers too. Let me know what values I should use for
testing.
Scale factor has to be = max number of clients you use, else you're
just measuring serialization on the
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I think we are on track for Monday beta.
One thing that I think absolutely *must* happen before we can go beta
is to fix the documentation build process at hub.org. Until the online
developer docs are up-to-date, how are beta testers going to know
OK, testing now with 1000 backends and 2000 buffers. Will report.
Bruce Momjian [EMAIL PROTECTED] writes:
No scale factor, as I illustrated from the initialization command I
used. Standard buffers too. Let me know what values I should use for
testing.
Scale factor has to be = max
On Sat, 29 Sep 2001, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, I think we are on track for Monday beta.
One thing that I think absolutely *must* happen before we can go beta
is to fix the documentation build process at hub.org. Until the online
developer docs are
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
No idea but it seemed like a
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
How hard would it be to pre-fork an extra backend
How are you going to pass the connection socket to an already-forked
child process? AFAIK there's no remotely portable way ...
No idea but it
Tom Lane wrote:
This approach would only work as far as saving the fork() call itself,
not the backend setup time. Not sure it's worth the trouble. I doubt
that the fork itself is a huge component of our start time; it's setting
up all the catalog caches and so forth that's expensive.
On
28 matches
Mail list logo
