Tom Lane wrote:
> Kevin Brown <[EMAIL PROTECTED]> writes:
> > The goal here is simply to make it obvious to a system administrator where
> > the PG data directory that a given postmaster is using resides.
>
> Why would it not be sufficient to add a read-only GUC variable that
> tells that? Connec
David Blasby <[EMAIL PROTECTED]> writes:
> Humm -- strange results here:
> typedef struct
> {
> float xmin;
> float ymin;
> float xmax;
> float ymax;
> } BOX2DFLOAT4;
> This takes about 18,000 ms to do a nested query with 10,000 iterations.
> typedef struct
> {
> flo
Joe Conway wrote:
Tom Lane wrote:
Personally I rely quite a lot on setting PGDATA to keep straight which
installation I'm currently working with, so I'm not going to be happy
with a redesign that eliminates that variable without providing an
adequate substitute :-(
I'll second that.
I'll thir
Humm -- strange results here:
typedef struct
{
float xmin;
float ymin;
float xmax;
float ymax;
} BOX2DFLOAT4;
This takes about 18,000 ms to do a nested query with 10,000 iterations.
typedef struct
{
float xmin;
float ymin;
float xmax;
David Blasby <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'd suggest profiling the backend with both key types to get an idea of
>> where the time is going.
> I've been trying to use gprof to do some profiling, but I'm having
> troubles. Whats the best way to profile?
It's not hard; the on
Tom Lane wrote:
I'd suggest profiling the backend with both key types to get an idea of
where the time is going.
I've been trying to use gprof to do some profiling, but I'm having
troubles. Whats the best way to profile?
PS: actually, allowing for the 12-byte index tuple overhead, you
couldn't
David Blasby <[EMAIL PROTECTED]> writes:
> The old way used a BOX (bounding box of 4 doubles) as the key in the index.
> The new way uses a bounding box of 4 single-precision floats (its only
> 16 bytes long - a BOX is 32).
> It turns out this is not the case - its significantly slower. I think
Jürgen Cappel wrote:
Point 1 I completely agree on: byte order, alignment, padding, etc.
is different for each platform and data cannot directly be exchanged.
Point 2: who really needs C++ ??
We use it, a multi path TCP router written in C++ and behind
there is a Postgresql...
Regards
Gaetano Mend
Couple of observations:
1. Are you sure your data is handled as 32 bit all the way through? Run
time casting will offset performance gains on 32 bit floats. Is your
comparison routine casting to double?
I thought this might be the case - but I thought it would be small. The
only place it might
I just tried an experiment that I thought would improve the performance
of the PostGIS spatial index.
The old way used a BOX (bounding box of 4 doubles) as the key in the index.
The new way uses a bounding box of 4 single-precision floats (its only
16 bytes long - a BOX is 32). I thought that
FYI for those of you tracking Linux development
kernel performance on PostgreSQL.
-Forwarded Message-
From: Mary Edie Meredith <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: DBT3-pgsql large performance improvement 2.6.6-rc1
Date: Fri, 16 Apr 2004 09:51:47 -0700
Performance in DBT-3
Hans, Andrew,
> > I have learned (please correct me if I am wrong) that people tend to
> > look in contrib before they look at gborg.
pgFoundry/project.postgresql.org will be up by next week, I promise.
Working on it now.
This should increase the visibility of non-core components.
--
-Jos
Scott,
> the sad thing is that while MySQL implemented a -ansi switch that
> supposedly turns on ansi compliance, it only fixes about 1/2 of all the
> non-compliance issues. Yet another half-implemented feature... :)
Plus they completely broke ansi-compliance with the latest version of
mysqld
On Fri, Apr 16, 2004 at 08:10:20AM -0400, Andrew Sullivan wrote:
> On Mon, Apr 05, 2004 at 06:33:51PM +0200, Hans-J?rgen Sch?nig wrote:
> >
> > I have learned (please correct me if I am wrong) that people tend to
> > look in contrib before they look at gborg.
>
> This may be true, but if so, per
Shalu Gupta <[EMAIL PROTECTED]> writes:
> I want to access the RelOptInfo data structure from the executor module.
You can't, because it doesn't exist any more. RelOptInfo is a planner
internal data structure, and is probably pfree'd before the executor starts.
Perhaps you could explain your pr
On Fri, 16 Apr 2004, Christopher Kings-Lynne wrote:
> > I always ran one of the 2 scripts (can't remember which one) and after that
> > started checking the dump file, because there were things that didn't get
> > changed correctly[1].
> >
> > [1]: I always remember the first conversion I did.
On Mon, Apr 05, 2004 at 06:33:51PM +0200, Hans-J?rgen Sch?nig wrote:
>
> I have learned (please correct me if I am wrong) that people tend to
> look in contrib before they look at gborg.
This may be true, but if so, perhaps it's a reason to add a
contrib/gborg directory with just a README that s
On Wed, Apr 07, 2004 at 09:39:15AM -0400, Jan Wieck wrote:
> the reason why dblink, dbmirror and the "rserv prototype" are under
> contrib/ while projects like erserver and slony1 live on gborg - just to
> take this class of projects as an example.
Since the rserv prototype actually does not wo
18 matches
Mail list logo