FYI: The DNSServiceDiscovery.h is Mac OS X specific and only kept
around for Mac OS X 10.2 and older compatiability. Apple has moved to
a cross platform impelentation with the dns_sd.h API available for OS
X, Win32, and most any posix type system.
Any reference to DNSServiceDiscovery.h in pgsql
On 9/11/05, Bruno Wolff III wrote:
On Sat, Sep 10, 2005 at 14:31:06 -0400, Andrew Dunstan wrote:
XHTML is simply a minimal reformulation of HTML in XML, and even uses
the HTML 4.01 definitions for its semantics. Given that, it's hard to
see why it should be considered a bad thing.
Here is
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i have seen that the corrupted page has
actually been zeroed out.
my question is: are there
On Sun, Sep 11, 2005 at 01:12:34PM +0200, Hans-Jürgen Schönig wrote:
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i have seen that the
Hi,
I have tried to post the following question in the general
malinglist, but haven't got any respons. I really hope
some pgsql-developer can help.
Btw. this is my first mail to this list, so please bear
with me.
I'm a computer science student doing a thesis on paging
algorithms, both from a
sir,
i'am getting different o/p for the same program code as well as the data base is the same .twice the output is being printed on some machines whereas correct o/p on some.the program code is
create or replace function f() return int4 as'
c1 cursor for select empname from emp;
e1
On Saturday 10 September 2005 12:10, Andrew Dunstan wrote:
Is there an HTML standard that we try to follow in our HTML docs such as
FAQs?
If there isn't an explicit standard, may I suggest that we adopt XHTML
1.0 as the standard?
Really the FAQ files need to be able to validate when viewed
So far, we have tended to use -fpic to compile position-independent code
until we have received some sort of overflow that forced the use of
-fPIC. Since 8.0, the makefiles to build shared libraries are also
available to external modules through the pgxs system, so we cannot
exactly check
Tom Lane [EMAIL PROTECTED] writes:
It'd be nice to get out from under the fixed-size-shmem restriction, but
I don't know any very portable way to do that.
Without knowing that part of the code at all it seems to me the logical
approach would be to make the fsm steal its pages out of the
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i have seen that the
Peter Eisentraut [EMAIL PROTECTED] writes:
So far, we have tended to use -fpic to compile position-independent code
until we have received some sort of overflow that forced the use of
-fPIC. Since 8.0, the makefiles to build shared libraries are also
available to external modules through
Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= [EMAIL PROTECTED] writes:
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i have
Tom Lane wrote:
The thought behind my suggestion was that the current max_fsm_pages
default of 2 pages is enough to track free space in a database of
maybe a few hundred megabytes. The other defaults are sized
appropriately for machines with about that much in main memory. This
doesn't
Tom Lane wrote:
PL/Java is bigger than the whole backend?
No, it's not, but the backend is not compiled as position-independent.
The reason for -fpic vs -fPIC (on the machines where it makes any
difference at all) is that the former is faster.
I don't doubt that, but out of curiosity,
On Sun, Sep 11, 2005 at 12:15:01PM -0400, Greg Stark wrote:
It'd be nice to get out from under the fixed-size-shmem restriction, but
I don't know any very portable way to do that.
Without knowing that part of the code at all it seems to me the logical
approach would be to make the fsm
On Sun, Sep 11, 2005 at 01:12:34PM +0200, Hans-Jürgen Schönig wrote:
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i have seen that the
On Sun, Sep 11, 2005 at 05:49:40PM +0200, Peter Eisentraut wrote:
So far, we have tended to use -fpic to compile position-independent code
until we have received some sort of overflow that forced the use of
-fPIC. Since 8.0, the makefiles to build shared libraries are also
available to
Alvaro Herrera wrote:
On Sun, Sep 11, 2005 at 01:12:34PM +0200, Hans-Jürgen Schönig wrote:
in the past we have faced a couple of problems with corrupted system
tables. this seems to be a version independent problem which occurs on
hackers' from time to time.
i have checked a broken file and i
* Peter Eisentraut ([EMAIL PROTECTED]) wrote:
Tom Lane wrote:
The reason for -fpic vs -fPIC (on the machines where it makes any
difference at all) is that the former is faster.
I don't doubt that, but out of curiosity, considering that everyone else
is using libtool, and libtool always
On Sat, Sep 10, 2005 at 12:11:52PM +0100, rajinder ruprai wrote:
i'am getting different o/p for the same program code as well as
the data base is the same .twice the output is being printed on
some machines whereas correct o/p on some.the program code is
[...]
raise notice ' 'emp name %' ',
I've recently been taking another look at the test case shown here:
http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php
This is the infamous context swap storm problem that we've hacking
at for so long. After the 8.1 buffer manager redesign, the problem
of contention for the
The test case I just posted shows that our spinlock code, which we had
thought largely done, is once again becoming a performance bottleneck.
It's time to resurrect some of the ideas we kicked around in early
2002, and didn't pursue because we decided spinlocks weren't our major
performance
On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
I kinda suspect that the cmpb test is a no-op or loss on all
Intelish processors: it can only be a win if you expect a lot
of contention for the spin lock, but in percentage terms we still
have a very low conflict rate, so in most
On Sun, 11 Sep 2005, Tom Lane wrote:
The files for the updated test case are attached if anyone else wants
to try it. They are:
test_setup.sql Run this to create the test tables
test_run.sqlA version of the test query that will run
pretty nearly
Simon Riggs wrote:
Are we sure there is just 3 cases?
I haven't exhaustively checked, but I think those are the main cases.
Even if case (3) is not that common, I still want to know it is
occurring, to see what effect or overhead it has.
I don't want it to be more verbose than the other
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
I kinda suspect that the cmpb test is a no-op or loss on all
Intelish processors:
I think an important question is wether this is for x86_64 in
general, of opteron specific. It could be that it's
* Tom Lane ([EMAIL PROTECTED]) wrote:
Kurt Roeckx [EMAIL PROTECTED] writes:
On Sun, Sep 11, 2005 at 05:59:49PM -0400, Tom Lane wrote:
I kinda suspect that the cmpb test is a no-op or loss on all
Intelish processors:
I think an important question is wether this is for x86_64 in
Peter Eisentraut [EMAIL PROTECTED] writes:
The reason for -fpic vs -fPIC (on the machines where it makes any
difference at all) is that the former is faster.
I don't doubt that, but out of curiosity, considering that everyone else
is using libtool, and libtool always uses -fPIC, what
I need a way to tell how many pages loaded from disk for a particular
index seek operation.
What I did is to set a global flag to true before calling the
following statement
(inside index_getnext() in /backend/access/indexam.c)
found = DatumGetBool(FunctionCall2(scan-fn_getnext,
Greg Stark [EMAIL PROTECTED] writes:
... mixing -fpic and -fPIC libraries is a problem.
Is it? I would think having two options would be essentially unworkable
if so.
regards, tom lane
---(end of broadcast)---
TIP 6:
* Tom Lane ([EMAIL PROTECTED]) wrote:
My proposal therefore is to do #2, #3, and #4, and to modify the TAS
assembly code at least on x86_64. Together, these changes bring
my test case on a 4-way Opteron from
N, runtime: 1 36s 2 61s 4 105s 8 198s
em64t, 2 proc + 2 HT, 3.4ghz, 4G,
Stephen Frost [EMAIL PROTECTED] writes:
em64t, 2 proc + 2 HT, 3.4ghz, 4G, 2.6.12:
N, runtime: 1 31s 2 47s 4 86s 8 159s
N, runtime: 1 32s 2 53s 4 90s 8 169s
Er, which (or both) of the two patches did you apply here?
regards, tom lane
Tom Lane wrote:
Anyone have SMP boxes of other types that they can try this on?
For those of us running antiques:
2x PIII 1Ghz 2G
Running on FreeBSD 6.0beta4 (non-debug kernel)
8.0.3:
N runtime: 1 158s 2 271s 4 567s
8.1beta1 (2005-08-28):
N runtime: 1 85s 2 139s 4 220s
Wow - a
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
em64t, 2 proc + 2 HT, 3.4ghz, 4G, 2.6.12:
N, runtime: 1 31s 2 47s 4 86s 8 159s
N, runtime: 1 32s 2 53s 4 90s 8 169s
Er, which (or both) of the two patches did you apply here?
Applied both,
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Er, which (or both) of the two patches did you apply here?
Applied both, sorry that wasn't clear.
Thanks. If you've got the time, could you try the two patches
separately and see what you get?
Tom Lane [EMAIL PROTECTED] wrote
My proposal therefore is to do #2, #3, and #4, and to modify the TAS
assembly code at least on x86_64. Together, these changes bring
my test case on a 4-way Opteron from
Some changes are based on tests and heuristics, so can we make them into the
configure
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
* Tom Lane ([EMAIL PROTECTED]) wrote:
Er, which (or both) of the two patches did you apply here?
Applied both, sorry that wasn't clear.
Thanks. If you've got the time, could you try the two patches
Tom Lane [EMAIL PROTECTED] writes:
Something else to consider is the OS you're using. I've been
told that Linux isn't that good in NUMA and FreeBSD might be
better.
It's hard to see how the OS could affect behavior at the level of
processor cache operations --- unless they did
* Stephen Frost ([EMAIL PROTECTED]) wrote:
Thanks. If you've got the time, could you try the two patches
separately and see what you get?
Sure.
[...]
Just to be clear- this was from a completely default 'make install'
using the Debian configure options from 8.0.3 (which aren't that
Qingqing Zhou [EMAIL PROTECTED] writes:
Some changes are based on tests and heuristics, so can we make them into the
configure script so the choice could be made automatically?
It's a bit premature to propose that, when we don't yet know if the
suggested changes are a win or loss under any
Tom Lane wrote:
I attach two proposed patches: the first removes the cmpb/jne from
the x86 TAS assembly code, and the second one does the s_lock changes
enumerated as points #2, #3, #4. The first one in particular needs
more testing to see if it hurts performance on any non-Opteron x86
chips.
41 matches
Mail list logo
