.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from
Hi Tom,
Thanks for your criticism on this.
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 11 January 2004 17:04
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestions for analyze patch required...
Mark Cave-Ayland [EMAIL PROTECTED
Hi Tom,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 13 January 2004 18:08
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] Suggestions for analyze patch required...
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I agree that the custom
the index entries using the operator and then call
geometry_overlap() function with the full tuples from the heap. However,
it seems geometry_overlap() is never called from an index scan made
using the operator :( Can anyone point out where I'm going wrong?
Many thanks,
Mark.
---
Mark Cave-Ayland
the
problem for him either).
Many thanks,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you
--pgxs
returning the wrong thing?
Kind regards,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any attachments are confidential to the intended
recipient and may also be privileged
Hi Tom,
What needs more discussion is that it seems to me to make sense to extend
the standard
opclasses to handle the four Y-direction operators comparable to the
X-direction
operators that are already there, that is above, below, overabove,
and
overbelow.
As part of PostGIS
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 24 June 2005 14:27
To: Mark Cave-Ayland (External)
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; oleg@sai.msu.su;
pgsql-hackers@postgresql.org; 'PostGIS Development Discussion'
Subject: Re: Fixing r-tree semantics
Hi guys,
I lean with you and Tom. While running it over the same libpq protocol
would be helpful in some ways, it would have a lot of drawbacks and
would really change the function of libpq. I think a separate debugging
protocol is in order.
Just putting on my network hat for a
Date: Thu, 04 Aug 2005 11:12:58 -0400
From: Tom Lane [EMAIL PROTECTED]
To: Matteo Beccati [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Subject: Re: Enhanced containment selectivity function
Message-ID: [EMAIL PROTECTED]
Matteo Beccati [EMAIL PROTECTED] writes:
This also made me
Hi everyone,
I'm currently in the middle of trying to implement a cache for a PostGIS
server-side function that uses an external library with an expensive startup
cost, and was hoping to find some advice on the best way to implement it.
The function currently takes 2 parameters - a customised C
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 07 November 2005 23:06
To: Mark Cave-Ayland (External)
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Any advice about function caching?
(cut)
If you want per-query state, keep it in a data structure
Hi strk,
(cut)
Taking a look at join selectivity...
For a query like this:
SELECT id FROM table1, table2
WHERE table1.geom table2.geom;
RESTRICT selectivity is invoked twice and
JOIN selectivity is invoked once.
The RESTRICT code is not able to find a costant part
Hi strk,
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 13 December 2004 14:05
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]
Subject: Re: [postgis-devel] RE: join selectivity
On Mon, Dec 13, 2004 at 12:16:15PM -, Mark Cave-Ayland wrote:
Hi strk
Hi Tom,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 13 December 2004 17:16
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] join selectivity
Mark Cave-Ayland [EMAIL PROTECTED] writes:
For a query
Hi Tom,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 16 December 2004 17:56
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] join selectivity
Mark Cave-Ayland [EMAIL PROTECTED] writes:
OK I think
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 16 December 2004 15:55
To: Mark Cave-Ayland
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [HACKERS] join selectivity
Mark Cave-Ayland [EMAIL PROTECTED] writes:
...and with two
Date: Wed, 12 Jan 2005 18:45:09 -0800
From: Jeff Davis [EMAIL PROTECTED]
To: Alvaro Herrera [EMAIL PROTECTED]
Cc: pgsql-hackers@postgresql.org
Subject: Re: Much Ado About COUNT(*)
Message-ID: [EMAIL PROTECTED]
(cut)
Thanks for the link. It looks like it breaks it up into chunks of about
-Original Message-
From: Jeff Davis [mailto:[EMAIL PROTECTED]
Sent: 19 January 2005 21:33
To: Alvaro Herrera
Cc: Mark Cave-Ayland; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Much Ado About COUNT(*)
To fill in some details I think what he's saying
-Original Message-
From: Richard Huxton [mailto:[EMAIL PROTECTED]
Sent: 20 January 2005 12:45
To: D'Arcy J.M. Cain
Cc: Mark Cave-Ayland; [EMAIL PROTECTED];
[EMAIL PROTECTED]; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Much Ado About COUNT(*)
D'Arcy J.M. Cain wrote
Hi everyone,
I'm trying to install a copy of PostgreSQL 7.3.8 on FC3 x86_64, and having a
very strange problem with shared memory in that PostgreSQL seems to be
taking far too many semaphores for the parameters in the postgresql.conf
file. I've raised this with some of the members of the IRC
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 31 January 2005 16:35
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 7.3.8 under FC3 takes excessive semaphores?
(cut)
Judging by the symptoms, you have built a version with what
we
Hi Tom and others,
I think the correct solution is not to mess with what's admittedly a
legacy aspect of
our client API. Instead we should invent the INSERT RETURNING and
UPDATE RETURNING
commands that have been discussed repeatedly (see the pghackers archives).
That would
allow people to
Hi Tom,
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 02 February 2005 15:35
To: Mark Cave-Ayland
Cc: 'Alvaro Herrera'; 'Michael Fuhr'; 'Mitch Pirtle'; 'Tatsuo
Ishii'; pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: Re: [NOVICE] Last ID Problem
(cut
Hi Tom,
I was profiling a case involving UPDATEs into a table with too many
indexes (brought to mind by mysql's sql-bench, about which more later) and
got this rather surprising result for routines costing more than 1% of the
total runtime:
(cut)
I suppose that the bulk of the CPU cycles
-Original Message-
From: Mark Cave-Ayland [mailto:[EMAIL PROTECTED]
Sent: 07 March 2005 11:04
To: '[EMAIL PROTECTED]'
Cc: 'pgsql-hackers@postgreSQL.org'
Subject: Re: Cost of XLogInsert CRC calculations
(cut)
I suppose that the bulk of the CPU cycles being attributed
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 10 May 2005 23:22
To: Simon Riggs
Cc: Bruce Momjian; Mark Cave-Ayland (External);
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
That's awfully vague --- can't you
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: 12 May 2005 02:46
To: Simon Riggs
Cc: Mark Cave-Ayland (External); 'Tom Lane'; 'Bruce Momjian';
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
perhaps
-Original Message-
From: Simon Riggs [mailto:[EMAIL PROTECTED]
Sent: 12 May 2005 16:52
To: Mark Cave-Ayland (External)
Cc: 'Christopher Kings-Lynne'; 'Tom Lane'; 'Bruce Momjian';
pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] Cost of XLogInsert CRC calculations
(cut
-Original Message-
From: Mark Cave-Ayland [mailto:[EMAIL PROTECTED]
Sent: 16 May 2005 09:04
To: 'Simon Riggs'
Cc: 'Christopher Kings-Lynne'; 'Tom Lane'; 'Bruce Momjian';
'pgsql-hackers@postgresql.org'
Subject: RE: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
The program
.
WebBased Ltd
17 Research Way
Plymouth
PL6 8BT
T: +44 (0)1752 797131
F: +44 (0)1752 791023
W: http://www.webbased.co.uk
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 16 May 2005 15:01
To: Mark Cave-Ayland (External)
Cc: pgsql-hackers@postgresql.org
Subject
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 16 May 2005 17:36
To: Mark Cave-Ayland (External)
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
I did some experimentation and concluded that gcc is screwing
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 18 May 2005 06:12
To: Greg Stark
Cc: Bruce Momjian; Manfred Koizar; Mark Cave-Ayland
(External); pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
Greg Stark [EMAIL
-Original Message-
From: Manfred Koizar [mailto:[EMAIL PROTECTED]
Sent: 25 May 2005 20:25
To: Manfred Koizar
Cc: Tom Lane; Greg Stark; Bruce Momjian; Mark Cave-Ayland
(External); pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut
-Original Message-
From: Manfred Koizar [mailto:[EMAIL PROTECTED]
Sent: 25 May 2005 20:25
To: Manfred Koizar
Cc: Tom Lane; Greg Stark; Bruce Momjian; Mark Cave-Ayland
(External); pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 27 May 2005 15:00
To: Mark Cave-Ayland (External)
Cc: 'Manfred Koizar'; 'Greg Stark'; 'Bruce Momjian';
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
Mark Cave-Ayland
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 27 May 2005 15:00
To: Mark Cave-Ayland (External)
Cc: 'Manfred Koizar'; 'Greg Stark'; 'Bruce Momjian';
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
Not sure I
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 27 May 2005 17:49
To: Mark Cave-Ayland (External)
Cc: 'Manfred Koizar'; 'Greg Stark'; 'Bruce Momjian';
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
I went back
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 31 May 2005 17:27
To: Greg Stark
Cc: Mark Cave-Ayland (External); 'Manfred Koizar'; 'Bruce
Momjian'; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
The odds
Date: Tue, 31 May 2005 16:26:20 -0400
From: Tom Lane [EMAIL PROTECTED]
To: pgsql-hackers@postgreSQL.org
Subject: Quick-and-dirty compression for WAL backup blocks
Message-ID: [EMAIL PROTECTED]
(cut)
... make the WAL writing logic aware of the layout
of buffer pages --- specifically, to
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 04 June 2005 16:46
To: Mark Cave-Ayland (External)
Cc: pgsql-hackers@postgresql.org
Subject: Re: Quick-and-dirty compression for WAL backup blocks
(cut)
I've completed a test run for this (it's essentially MySQL's
Hi folks,
Looking ahead at some of the projects I'll be working on in the future, I'm
seeing that having an implementation of WITH/WITH RECURSIVE for working with
tree structures is going to be a very useful feature and so would like to
re-start the discussions on this to see whether this could
-Original Message-
From: Jonah H. Harris [mailto:[EMAIL PROTECTED]
Sent: 01 May 2006 14:56
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] WITH/WITH RECURSIVE implementation discussion
On 5/1/06, Mark Cave-Ayland [EMAIL PROTECTED] wrote:
The latest
Hi everyone,
Having browsed the TODO list, one of the items that I would be interested
on working on is a debugger for stored procedures. Having searched on this
topic in the archives, I'm still short of some answers that would allow me
to come up with a complete proposal that I can use to start
be done, perhaps some way of storing/retrieving metadata about an
index through GiST?
Cheers,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any attachments are confidential
Hi Tom,
Mark Cave-Ayland [EMAIL PROTECTED] writes:
However, each database column also has a spatial reference system
identifier (SRID) that specifies the coordinate system the
geometry is
in. What should happen is that given two geometries or
bounding boxes,
an error should
at
http://www.webbased.co.uk/mca/pgsql/. Andrew, if you are satisfied that
these work correctly on your RH7.3 install, there is no problem with
Lamar placing copies of them on the postgresql website for people to
download.
Cheers,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
change this to i386 so it will binaries will run on actual i386
machines? Can someone point me in the right direction?
Cheers,
Mark.
---
Mark Cave-Ayland
Webbased Ltd.
Tamar Science Park
Derriford
Plymouth
PL6 8BX
England
Tel: +44 (0)1752 764445
Fax: +44 (0)1752 764446
This email and any
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 29 May 2006 18:05
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal for debugging of server-side stored
procedures
(cut)
As far as the debug protocol details go, it'd be worth
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 09 June 2006 16:25
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: Proposal for debugging of server-side stored procedures
Some thoughts from another Tom...
Hi Tom,
Thanks
-Original Message-
From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
Sent: 09 June 2006 17:01
To: Mark Cave-Ayland
Cc: 'Tom Lane'; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Proposal for debugging of server-side stored
procedures
(cut)
Debugging embedded perl has some
-Original Message-
From: Thomas Hallgren [mailto:[EMAIL PROTECTED]
Sent: 11 June 2006 10:07
To: Mark Cave-Ayland
Cc: pgsql-hackers@postgresql.org
Subject: Re: Proposal for debugging of server-side stored procedures
Hi Tom,
(cut)
Obviously I'm not a Perl nor Python hacker. I just
On Sat, 2006-08-26 at 22:46 -0400, Jonah H. Harris wrote:
On 8/26/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
Actually I was thinking in the design rather than the code ...
Doh! We hadn't posted the design just yet. Let me write him and see
where he's at and we'll throw something together
On Mon, 2006-09-18 at 17:46 +0200, Matteo Beccati wrote:
Tom Lane ha scritto:
Matteo Beccati [EMAIL PROTECTED] writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is large enough? I feel a bit
Hi Tom,
Thanks for your initial thoughts on this.
On Wed, 2006-09-20 at 20:13 -0400, Tom Lane wrote:
(cut)
You really can't get away with having the identical representation for
CTEs and ordinary sub-selects in the range table. For instance, it
looks like your patch will think that
Hi everyone,
I'm in the process of generating the Windows installer for the latest
PostGIS 1.1.4 release and I'm getting a regression failure in one of
libpq applications - the application in question is generating a
segfault.
Testing so far shows that the regression tests pass without
On Sun, 2006-10-08 at 17:53 +0200, Magnus Hagander wrote:
AFAICT the backtrace and server log is indicating that the
crash is happening somewhere in libpq. If someone can help me
figure out how to load the libpq symbols into MingW's gdb
then I can get a better backtrace if required as I
Hi Magnus,
I finally got to the bottom of this - it seems that the flags being
passed to MingW's linker were incorrect, but instead of erroring out it
decided to create a corrupt executable. Here is the command line that
was being used to link the pgsql2shp.exe executable, along with the
the only
thing that is wrong is that a suitable ERROR message is missing?
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
-- Initial data
--
CREATE TABLE ctest (
id int8,
name varchar
);
INSERT
), is
there still scope for getting something like this in 8.4 - or this patch
still far shy of anything ready for a commit fest? I have a feeling that
working on this is something currently beyond my own capability :(
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http
---
0
(1 row)
So in other words, the contents of the temporary table has just
disappeared :(
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
-- Count script
create temp table tmp as select st_makepoint(random
bizarre interaction
between CLUSTER/VACUUM/autovacuum?
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
,
but I'd be interested to get some initial feedback as to whether the
introduction of a new MODULEDIR variable is the best way to add this new
piece of functionality.
Many thanks,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through
.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
installed in two separate
locations.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
diff --git a/src/makefiles/pgxs.mk b/src
Tom Lane wrote:
Why do DOCS still go into doc/contrib? Shouldn't that become
doc/$MODULEDIR for consistency?
Hmmm it looks as if the code was correct but I missed the comment at the
top of the file. Sorry for the confusion - revised version attached.
ATB,
Mark.
--
Mark Cave-Ayland
the information specified.
With perhaps some minor tweaks to some of the names and a rework of the
else clause in ginInsertEntry(), I feel this patch is reasonably close
to commit.
I shall now continue my review of the associated KNNGiST patch.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
works:
http://trac.osgeo.org/postgis/browser/trunk/postgis/Makefile.in
http://trac.osgeo.org/postgis/browser/trunk/regress/Makefile.in
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44
there is
a definite order of magnitude speed increase with this patch applied.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
--
Sent
Robert Haas wrote:
Here's an overview of where we stand with the remaining 14 patches,
according to my best understanding of the situation.
* rbtree - I have done a lot of work reviewing this, and Mark
Cave-Ayland has done some work on it, too. But there are some
unanswered performance
=# CREATE INDEX idin_rbtree_idx ON links2 USING gin (idin);
CREATE INDEX
Time: 1864013.526 ms
rbtest=# CREATE INDEX idout_rbtree_idx ON links2 USING gin (idout);
CREATE INDEX
Time: 1661200.454 ms
HTH,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc
On Sun, 2007-06-24 at 13:23 -0400, Andrew Dunstan wrote:
(cut)
On a somewhat related note, I have had spectacular lack of success in
getting either MSVC or MinGW builds to work on Vista - so much so that I
have currently abandoned my attempts on that platform and I resorted to
Tom Lane wrote:
There was recently another go-round on the postgis-devel list about
the same problem Mark Cave-Ayland complained about last year:
http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php
Basically, what is happening is a nestloop join where the inner
indexscan gets
: 272.185 ms
(8 rows)
So in conclusion, I think that patch looks good and that the extra time
I was seeing was due to RECHECK being applied to the operator, and
not the time being spent within the index scan itself.
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
doesn't seem to want to run at the moment
:( I'm wondering if it's related to either excess TOAST/palloc/pfree
somewhere in the code, but I'd definitely appreciate any pointers.
All these tests were done using PostgreSQL 8.3.1 and the latest PostGIS SVN.
Many thanks,
Mark.
--
Mark Cave-Ayland
geography_geom_centroid_idx on geography
(cost=0.00..8.28 rows=1 width=0) (actual time=43.218..286.535 rows=32880
loops=1)
Index Cond: (centroid ($0)::geometry)
Filter: (centroid ($0)::geometry)
Total runtime: 376.117 ms
(8 rows)
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open
in the coordinate sequence, but
nothing major. I've removed the -VARHDRSZ part just to check and it
doesn't make any difference.
Many thanks,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list
, VARSIZE_EXTERNAL(pgl));
PG_RETURN_POINTER(mem);
}
...and of course, this now takes the slower runtime of 2.5s.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers
converted to its bounding box (which would not require deTOASTing)
before being used as an index scan key.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers
on geography (cost=0.00..7092.00 rows=1 width=0)
(actual time=55.016..9073.084 rows=32880 loops=1)
Filter: (centroid $0)
Total runtime: 9117.174 ms
(7 rows)
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
if this is present.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
...
At the very least we have some more information on how an eventual
solution should work, and a test case to help analyse the effectiveness
of any potential solution.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via
of enabling some assertions in production
builds.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
Hi everyone,
I'm working on a piece of code for PostGIS to allow the loading of
projection configuration files from the share/postgresql directory, but
I can't find a way of getting this to work under Win32.
AIUI the way to do this would be to use a combination of my_exec_path
and get_share_path
On Mon, 2007-11-26 at 11:55 -0500, Tom Lane wrote:
I'm not sure why Mark's having a problem accessing my_exec_path ---
it *is* declared DLLIMPORT in miscadmin.h (which is where it counts,
AIUI) clear back to 8.0.
Bah, I think that is the source of the problem. Having grepped the
source for
On Mon, 2007-11-26 at 17:02 -0500, Tom Lane wrote:
I believe that that is talking specifically about shared libraries (or
DLLs in Windows-speak), and not about configuration or data files.
In particular, nothing under libdir would be a candidate to go under
sharedir, nor vice versa, since the
Hi everyone,
I think that I may have found a minor bug with PostgreSQL 8.3beta4 with
respect to md5 authentication. I actually discovered this on Win32, but
it appears that the behaviour is the same under Linux too.
As part of the PostGIS install under Win32, I have a few scripts that
check for
On Fri, 2007-12-07 at 11:03 -0500, Tom Lane wrote:
Hmmm ... it seems the problem is that we've defined
PQconnectionUsedPassword in such a way that it returns true (causing a
prompt) regardless of whether the reason for the connection failure was
a bad password or not. We might need to
On Sat, 2007-12-08 at 10:09 -0500, Tom Lane wrote:
My vote goes to (3), if the work can be done quickly, or (1) if it
can't.
Ditto.
I don't think it's a big problem to do, as long as we are agreed on
the behavior we want. In particular, consider:
1. If libpq obtains a password
On Sat, 2007-12-08 at 17:09 -0500, Tom Lane wrote:
So what I think we must do is split the function into two:
PQconnectionNeedsPassword: true if server demanded a password and there
was none to send (hence, can only be true for a failed connection)
PQconnectionUsedPassword: true if server
Hi everyone,
I believe that there is a small bug in src/port/rint.c when the input
parameter has a fractional part of 0.5 which is demonstrated by the
attached program. It appears that the PG version of rint() rounds in the
wrong direction with respect to glibc.
[EMAIL PROTECTED]:~$ ./test
On Sun, 2008-01-20 at 16:47 -0500, Tom Lane wrote:
Your proposed fix wouldn't make it act the same as glibc, only move the
differences around. I believe glibc's default behavior for the
ambiguous cases is round to nearest even number. You propose
replacing round towards zero, which is what
less
time than having to wait for someone like Alvaro or Tom to review and commit
several hundred KB of code.
This seems to fit more with the idea of a distributed SCM, although it
wouldn't be entirely out of the question to set up permissions using CVS/SVN.
ATB,
Mark.
--
Mark Cave-Ayland
forks might be used for, and (b) the name fails to be
inclusive of the data fork. Other suggestions anyone?
I believe that in the world of NTFS the concept is called streams:
http://support.microsoft.com/kb/105763.
HTH,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
-users/2010-April/026349.html.
Would LDFLAGS_EX in this case be what we need? If so, could it be
exposed via a pg_config --libpq option or similar?
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http
is picking up the wrong pg_config. Since
the path fix in the thread was not backported to 8.3, then the
presence of an another pg_config for PostgreSQL 8.3 in PATH will break
things :(
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control
a new release in time for 9.0...
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
Sirius Labs: http://www.siriusit.co.uk/labs
--
Sent via pgsql-hackers mailing list
http://postgis.refractions.net/pipermail/postgis-commits/2008-January/000199.html.
I appreciate it may not be 100% relevant, but I thought I'd flag it up
as possibly being a fault with the MingW putenv implementation.
HTH,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source
.
Interesting metaphor... ;)
ATB,
Mark.
--
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Sat, 2006-12-30 at 00:49 -0500, Jonah H. Harris wrote:
On 12/29/06, Bruce Momjian [EMAIL PROTECTED] wrote:
No code yet, and I don't remember who said they were working on it.
I'm still waiting to hear from Mark Cave-Ayland on whether he's going
to pick it up or whether I'll just do
1 - 100 of 137 matches
Mail list logo
