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
Tom Lane wrote:
>
>
> 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
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 wha
> 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 w
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 for
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
Tom Lane writes:
> The particular case that I ran into is that I've been in the habit
> of running test postmasters with "-o -F" to suppress fsync. Kernel
> tracing showed that checkpoint processes were issuing fsyncs anyway,
> and I eventually realized why: they're not seeing the command line
>
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.
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
> could want a different one.
This 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 ...
> >
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 i
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 ar
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
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
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
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 TimeZo
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I ran with 20 clients:
What scale factor? How many buffers?
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I ran with 20 clients:
>
> What scale factor? How many buffers?
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.
--
Bruce Momjian
Bruce Momjian wrote:
>
> How hard would it be to pre-fork an extra backend for the database a
> user just requested so if they next user asks for the same database, the
> backend would already be started?
The only problem I could see is the socket. The pre-forked() back-end would
have to do the
> 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 si
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
> 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
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 sor
How hard would it be to pre-fork an extra backend for the database a
user just requested so if they next user asks for the same database, the
backend would already be started?
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
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
"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 inter
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 t
> 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. (Tats
* 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
> 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 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
syste
> > 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 "
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 th
33 matches
Mail list logo
