Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I've applied this but I'm now having some second thoughts about it,
>> because I'm seeing an actual *decrease* in pgbench numbers from the
>> immediately prior CVS HEAD code.
> The attached patch requires the new row to fit, and 10% to
Christopher Browne wrote:
> It seems to me that there is some value in putting together a script
> that tries to identify some of the interesting bits of the toolchain.
Yeah; but why not just a bunch of commands, some of which are expected
to work on any particular machine, and save the whole out
Quoth [EMAIL PROTECTED] (Peter Eisentraut):
> Andrew Dunstan wrote:
>> Lately there have been some buildfarm registrations for "Debian
>> testing/unstable" or similarly described machines. I have kicked back
>> against these, as the description seems to me to be far too open
>> ended.
>
> Then agai
I'll look into this.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> I have just realized that the recent patches in pgbench have altered its
> behavior in a way that destroys reproducibility of results --- I'm
> seeing reported TPS numbers about twice what they were before that.
> I'd love to say we did so
I have just realized that the recent patches in pgbench have altered its
behavior in a way that destroys reproducibility of results --- I'm
seeing reported TPS numbers about twice what they were before that.
I'd love to say we did something in the past month that made the backend
2X faster, but sad
On Mon, Sep 11, 2006 at 07:05:12PM -0400, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> > > At first I meant that as a reductio ad absurdum argument, but, uh,
> > > come to think of it why *do* we have our own arbitrary precision
> > > l
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > At first I meant that as a reductio ad absurdum argument, but, uh,
> > come to think of it why *do* we have our own arbitrary precision
> > library? Is there any particular reason we can't use one of the
> > exis
Gregory Stark <[EMAIL PROTECTED]> writes:
> At first I meant that as a reductio ad absurdum argument, but, uh,
> come to think of it why *do* we have our own arbitrary precision
> library? Is there any particular reason we can't use one of the
> existing binary implementations?
Going over to binar
Tom Lane wrote:
> "Albe Laurenz" <[EMAIL PROTECTED]> writes:
> > Let me expand a little on some of the peculiarities of
> > shared libraries on AIX:
>
> > - A normal AIX shared library is called libXX.a
> > It is an 'ar' archive that contains the shared object(s).
>
> Ah, so the problem really
Tom Lane <[EMAIL PROTECTED]> writes:
> That's utterly irrelevant. The point is that there are standard
> applications today in which people need that much precision; therefore,
> the argument that "10^508 is far more than anyone could want" is on
> exceedingly shaky ground.
My point is those app
Congrats Jim!
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
Sent: Monday, September 11, 2006 02:12 PM Eastern Standard Time
To: pgsql-hackers@postgresql.org
Subject:[HACKERS] New job
While I'm sitting here in New Jer
Hello,
On Mon, 2006-09-11 at 13:11 -0500, Jim C. Nasby wrote:
> While I'm sitting here in New Jersey in a room with Bruce Momjian (aka
> Rock Star), I figured now would be a good time to announce my new
> employment. I'll be doing sales support/engineering from Austin.
Congrats Jim.
Cheers,
--
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> No, that got rejected as being too much of a restriction of the dynamic
>> range, eg John's comment here:
>> http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
> That logic seems questionable. John m
Tom Lane <[EMAIL PROTECTED]> writes:
> No, that got rejected as being too much of a restriction of the dynamic
> range, eg John's comment here:
> http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
That logic seems questionable. John makes two points:
a) crypto applications are wit
Tom Lane wrote:
> The buildfarm script already seems to record various info such as
> "uname" output on-the-fly. If we could get it to record compiler
> version ("gcc -v" is easy, but equivalent incantations for vendor
> compilers might be harder to find) and a few other facts on-the-fly,
> I thin
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> btw - the "hashjoin is bad" was more or less based on the observation
> that nearly all of the cpu is burned in hash-related functions in the
> profile (when profiling over a longer period of time those accumulate
> even more % of the time than in
For those who don't read all the threads, I'll repeat it here. I've put
up a wiki page working out the mysterious "XML support":
http://developer.postgresql.org/index.php/XML_Support
This is pretty much my talk from the conference.
The short status is that we have quite a bit of code ready and
Tom Lane wrote:
> Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
>> I'm about to do some benchmarking on -HEAD one some hardware I have
>> available and it seems I'm hitting a rather weird issue causing the osdl
>> dbt3 benchmark to run very slow and eating CPU time for hours ...
>
> Could we se
Tom Lane wrote:
> Even more interesting would be to fix things so that xml2 gets built
> as part of the regular contrib build, but I'm not sure if we're ready
> to add stuff to the configure script for the sole benefit of a
> contrib module.
It might be good to get the configury code out in this r
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> I'm about to do some benchmarking on -HEAD one some hardware I have
> available and it seems I'm hitting a rather weird issue causing the osdl
> dbt3 benchmark to run very slow and eating CPU time for hours ...
Could we see the actual EXPLAIN ANAL
On Mon, Sep 11, 2006 at 01:15:43PM -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > In any case it seems a bit backwards to me. Wouldn't it be better to
> > preserve bits in the case of short length words where they're precious
> > rather than long ones? If we make 0xxx th
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I agree that the lack of a fixed version designation is unsatisfactory.
> I'm not sure whether that is actually necessary, though. If PostgreSQL
> doesn't work on some machine, then that's a problem anyway.
The buildfarm script already seems to re
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is this an 8.2 thing?
You are joking, no?
> If not, is Numeric508 applied?
No, that got rejected as being too much of a restriction of the dynamic
range, eg John's comment here:
http://archives.postgresql.org/pgsql-general/2005-12/msg00246.php
I think a
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
>
>> well I think Andrew is more scared of having multiple boxes on the
>> buildfarm all stating to be "Debian testing" or "Debian unstable" but
>> without much information on how regulary those boxes are actually synced
>> to those moving/changi
Stefan Kaltenbrunner wrote:
> well I think Andrew is more scared of having multiple boxes on the
> buildfarm all stating to be "Debian testing" or "Debian unstable" but
> without much information on how regulary those boxes are actually synced
> to those moving/changing branches and causing discus
While I'm sitting here in New Jersey in a room with Bruce Momjian (aka
Rock Star), I figured now would be a good time to announce my new
employment. I'll be doing sales support/engineering from Austin.
--
Jim Nasby [EMAIL PROTECTED]
EnterpriseDBhttp://enterprisedb.com
---
Peter Eisentraut wrote:
> Andrew Dunstan wrote:
>> Lately there have been some buildfarm registrations for "Debian
>> testing/unstable" or similarly described machines. I have kicked back
>> against these, as the description seems to me to be far too open
>> ended.
>
> Then again, it would be usef
Why in the world is set_pglocale_pgservice() located in src/port/path.c?
I was just trying to find out why ecpg is failing on the Darwin
buildfarm members since I modified the arrangements for pulling in extra
libraries for AIX. The answer is that ecpglib needs path.c for
last_dir_separator(), an
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> In any case it seems a bit backwards to me. Wouldn't it be better to
>> preserve bits in the case of short length words where they're precious
>> rather than long ones? If we make 0xxx the 1-byte case it means
Hi!
I'm about to do some benchmarking on -HEAD one some hardware I have
available and it seems I'm hitting a rather weird issue causing the osdl
dbt3 benchmark to run very slow and eating CPU time for hours ...
it seems that the issue is caused by the following query:
(in case it gets linewrapped
Gregory Stark <[EMAIL PROTECTED]> writes:
> In any case it seems a bit backwards to me. Wouldn't it be better to
> preserve bits in the case of short length words where they're precious
> rather than long ones? If we make 0xxx the 1-byte case it means ...
Well, I don't find that real persuasiv
Gregory Stark wrote:
> I don't know if this changes the calculus but apparently we've
> already decided to go down the route of having Emacs local variables
> attached to every file in the source directory. We have things like
> this there:
I delete them from every file I edit, but I haven't been
Andrew Dunstan wrote:
> Lately there have been some buildfarm registrations for "Debian
> testing/unstable" or similarly described machines. I have kicked back
> against these, as the description seems to me to be far too open
> ended.
Then again, it would be useful to actually test on Debian
tes
Gregory Stark wrote:
>
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>
> > > Well it's irrelevant if we add a special data type to handle CHAR(1).
> >
> > In that case you should probably be using "char" ...
>
> Well "char" doesn't have quite the same semantics as CHAR(1). If that's the
> consen
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> I'm imagining that it would give you the same old uncompressed in-memory
>> representation as it does now, ie, 4-byte length word and uncompressed
>> data.
> Sure, but how would you know? Sometimes you would get a
On Sun, 2006-09-10 at 21:16 -0400, Tom Lane wrote:
> After further thought I have an alternate proposal
(snip)
> * If high order bit of datum's first byte is 0, then it's an
> uncompressed datum in what's essentially the same as our current
> in-memory format except that the 4-byte length word m
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I see this in the CVS commits for 8.2. Did we determine the proper
number of lock partitions? Should it be based on the number of buffers
or concurrent sessions allowed?
No. NUM_LOCK_PARTITIONS needs to be a compile-time constant for
Tom Lane wrote:
Michael Fuhr <[EMAIL PROTECTED]> writes:
contrib/xml2 currently has PG_MODULE_MAGIC in xslt_proc.c, which
results in a runtime error on systems that built the module without
support for libxslt per the comments in the Makefile. Should
PG_MODULE_MAGIC be in xpath.c instead?
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Well it's irrelevant if we add a special data type to handle CHAR(1).
>
> In that case you should probably be using "char" ...
Well "char" doesn't have quite the same semantics as CHAR(1). If that's the
consensus though then I can work on either fi
Thank you for your reply.
I found my bug in the code which made the function behave strangely.
On Mon, 2006-09-11 at 14:23 +0530, Abhijit Menon-Sen wrote:
> At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
> >
> > What are we testing to be NULL here?
> > Do we expect str to changed at l
I forgot the mention that I did not want to support those two in my
initial version. But yesterday I started to work on those anyway :)
typreceive and typsend
On Mon, 2006-09-11 at 15:58 +0200, Markus Schaber wrote:
> Hi, Gevik,
>
> Gevik Babakhani wrote:
>
> > typreceive = not supported
>
Mark Wong <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It would be nice to see some results from the OSDL tests with, say, 4,
>> 8, and 16 lock partitions before we forget about the point though.
>> Anybody know whether OSDL is in a position to run tests for us?
> Yeah, I can run some dbt2 tes
Michael Fuhr <[EMAIL PROTECTED]> writes:
> contrib/xml2 currently has PG_MODULE_MAGIC in xslt_proc.c, which
> results in a runtime error on systems that built the module without
> support for libxslt per the comments in the Makefile. Should
> PG_MODULE_MAGIC be in xpath.c instead?
[ examines xml2
On Monday 11 September 2006 11:05, Thomas Hallgren wrote:
> Jan de Visser wrote:
> > On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
> >> 2a) Three input formats are supported.
> >> example:
> >> insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
> >> insert into tbl (f
Jan de Visser wrote:
On Friday 08 September 2006 15:18, Gevik Babakhani wrote:
2a) Three input formats are supported.
example:
insert into tbl (fld) values('1dfb39af-b56a-40b8-a903-b5b31567c3ce');
insert into tbl (fld) values('{1dfb39af-b56a-40b8-a903-b5b31567c3ce}');
insert into tbl (fld) value
On Mon, Sep 11, 2006 at 03:13:36PM +0100, Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> >> Also Heikki points out here that it would be nice to allow for the case
> >> for a
> >> 0-byte header.
> >
> > I don't think there's enough code space for that; at least not compared
> > t
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Let me expand a little on some of the peculiarities of
> shared libraries on AIX:
> - A normal AIX shared library is called libXX.a
> It is an 'ar' archive that contains the shared object(s).
Ah, so the problem really boils down to funny naming conve
Gregory Stark wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> >> Also Heikki points out here that it would be nice to allow for the case
> >> for a
> >> 0-byte header.
> >
> > I don't think there's enough code space for that; at least not compared
> > to its use case.
>
> Well it's irrelevant
Tom Lane wrote:
>> It builds fine on AIX 5.3 as long as you tell it to link with
>> libpq.so. Static builds against libpq.a will fail.
>
> Hm. We have been assuming that AIX's problem is that dynamic
libraries
> don't remember their dependencies properly, but maybe the real issue
is
> that it pre
Tom Lane <[EMAIL PROTECTED]> writes:
>> Also Heikki points out here that it would be nice to allow for the case for a
>> 0-byte header.
>
> I don't think there's enough code space for that; at least not compared
> to its use case.
Well it's irrelevant if we add a special data type to handle CHAR(
Andrew Dunstan wrote:
Lately there have been some buildfarm registrations for "Debian
testing/unstable" or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open ended.
Likewise, I also have difficulty with Gentoo because a version th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> I don't know if this changes the calculus but apparently we've already
>> decided
>> to go down the route of having Emacs local variables attached to every file
>> in
>> the source directory. We have things like this there:
>>
Hi, Gevik,
Gevik Babakhani wrote:
> typreceive = not supported
> typsend = not supported
Any reason why you don't want to support binary transmissions?
Thanks,
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against softwa
Gregory Stark wrote:
I don't know if this changes the calculus but apparently we've already decided
to go down the route of having Emacs local variables attached to every file in
the source directory. We have things like this there:
Only in the docs.
cheers
andrew
Martijn van Oosterhout writes:
> Static links are going to require it on every platform, not just AIX.
> The question do we want to ask is how easy do we want to make static
> linking, because the same treatment will have to apply to -lssl,
> -lcrypto, -lkrb5, -lk5crypto and quite possibly others.
Lately there have been some buildfarm registrations for "Debian
testing/unstable" or similarly described machines. I have kicked back
against these, as the description seems to me to be far too open ended.
Likewise, I also have difficulty with Gentoo because a version there
seems to describe
"Albe Laurenz" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Applied, but without that last part. It builds OK for me on Darwin,
>> which is moderately picky about that sort of thing, but someone should
>> try AIX.
> It builds fine on AIX 5.3 as long as you tell it to link with
> libpq.so. Sta
I don't know if this changes the calculus but apparently we've already decided
to go down the route of having Emacs local variables attached to every file in
the source directory. We have things like this there:
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
Adrian Maier wrote:
On 9/11/06, Jeremy Drake <[EMAIL PROTECTED]> wrote:
On Mon, 11 Sep 2006, Adrian Maier wrote:
> It's not clear to me where does that date-in-the-future come from.
> The machine's
> date is set correctly:
> $ date
> Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the
Tom Lane <[EMAIL PROTECTED]> writes:
> Mark Dilger <[EMAIL PROTECTED]> writes:
> > ... The argument made upthread that a
> > quadratic number of conversion operators is necessitated doesn't seem
> > right to me, given that each type could upcast to the canonical built in
> > type. (int1 => sma
I intend to play with some optimizer aspects. Just for fun. I'm a
novice in the DBMS development so I can not promise any available
results but if it can be useful even as yet another failed attempt I
will try.
That's what I want to do:
1. Replace not very useful indexCorrelation with indexCluster
Hi, Tom,
Tom Lane wrote:
> The only way we could pack stuff without alignment is to go over to the
> idea that memory and disk representations are different --- where in
> this case the "conversion" might just be a memcpy to a known-aligned
> location. The performance costs of that seem pretty d
On Mon, Sep 11, 2006 at 12:13:29PM +0200, Albe Laurenz wrote:
> > Applied, but without that last part. It builds OK for me on Darwin,
> > which is moderately picky about that sort of thing, but someone should
> > try AIX.
>
> It builds fine on AIX 5.3 as long as you tell it to link with
> libpq.s
Tom Lane wrote:
>> Here is a new patch that replaces the previous one; it adds two
>> macros LDAP_LIBS_FE and LDAP_LIBS_BE for frontend and backend,
>> respectively.
>
>> I did not only add them to the Makefile for interfaces/libpq,
>> but also everywhere something is linked against libpq in case
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> I'm a bit confused by this and how it would be handled in your sketch. I
>> assumed we needed a bit pattern dedicated to 4-byte length headers because
>> even though it would never occur on disk it would be necessa
On 9/11/06, Jeremy Drake <[EMAIL PROTECTED]> wrote:
On Mon, 11 Sep 2006, Adrian Maier wrote:
> It's not clear to me where does that date-in-the-future come from.
> The machine's
> date is set correctly:
> $ date
> Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST time zone, and I
On Mon, 11 Sep 2006, Adrian Maier wrote:
> It's not clear to me where does that date-in-the-future come from.
> The machine's
> date is set correctly:
> $ date
> Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST time zone, and I can say from
first-hand experience that the current t
Hello,
I'm trying to put the cassowary buildfarm member back to work (it's
been inactive
for almost a month because i've moved to another project and switched
the machine).
The run_build script has trouble with sending the test results. The error is :
Status Line: 491 bad ts parameter - 1157995
At 2006-09-11 10:25:22 +0200, [EMAIL PROTECTED] wrote:
>
> What are we testing to be NULL here?
> Do we expect str to changed at line 1715
No. (Read the comment just above the function.)
The code is like this, starting from line 1703:
if (str == NULL && flinfo->fn_strict)
return (Da
On Sat, 9 Sep 2006 at 15:57, Lamar Owen wrote:
> [...] or annoying the small number of people who NFS mount their
> datadirs?
This problem is not limited to NFS. It can happen with any FS just by
reversing (for whatever reason) the order of mounting the FS and
starting the PostgreSQL server.
I am a little stuck of a question.
In fmgr.c:1698, function "InputFunctionCall" at line 1718
/* Should get null result if and only if str is NULL */
if (str == NULL)
{
What are we testing to be NULL here?
Do we expect str to changed at line 1715
( result = FunctionCallInvoke(&fcinf
71 matches
Mail list logo
