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.
"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 an
* 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
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 d
* 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 patch
"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
c
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:
> 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?
Applie
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 huge
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 ([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,
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: ex
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,
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,
* 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
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 t
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 c
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 nearl
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
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 problem
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 Bu
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 %' ',
* 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 a
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
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
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 th
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
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, cons
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 s
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 s
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 thro
=?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 th
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
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 anym
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 vi
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 emp.ename%type;
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 the
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 th
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 a
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.
>
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 sh
41 matches
Mail list logo