All,
As we try and make PostGIS more "parallel sensitive" we have been added
costs to our functions, so that their relative CPU cost is more accurately
reflected in parallel plans.
This has resulted in an odd side effect: some of our "wrapper" functions
stop giving index scans in plans [1]. This
Lane wrote:
> > Paul Ramsey writes:
> >>> Whether I get a parallel aggregate seems entirely determined by the
> number
> >>> of rows, not the cost of preparing those rows.
> >
> >> This is true, as far as I can tell and unfortunate. Feeding tables wit
On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila
wrote:
> On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane wrote:
> > Paul Ramsey writes:
> >>> Whether I get a parallel aggregate seems entirely determined by the
> number
> >>> of rows, not the cost of preparing those ro
Just clarifying myself a little, since I made a dumb error partway through.
On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey
wrote:
> I'm working on a custom aggregate, that generates a serialized data
> format. The preparation of the geometry before being formatted is pretty
> int
I'm working on a custom aggregate, that generates a serialized data format.
The preparation of the geometry before being formatted is pretty intense,
so it is probably a good thing for that work to be done in parallel, in
partial aggregates. Here's an example SQL call:
EXPLAIN analyze
SELECT lengt
built against Postgres 9.0!) I hope we take their contribution
seriously, because it would truly move Postgres's temporal support
beyond any database on the market.
Yours,
Paul
[1] https://files.ifi.uzh.ch/boehlen/Papers/modf174-dignoes.pdf
[2] http://www.zora.uzh.ch/id/eprint/130374/1/Extendin
On Sat, Aug 5, 2017 at 6:22 PM, Robert Haas wrote:
> On Sat, Aug 5, 2017 at 4:28 PM, Paul A Jungwirth
> wrote:
>> I don't have an opinion on the urgency of back-porting a fix, but if
>> pg_stop_backup(boolean) allows for inconsistent backups, it does sound
>> like
On Sat, Aug 5, 2017 at 1:28 PM, Paul A Jungwirth
wrote:
> On Sat, Aug 5, 2017 at 7:51 AM, Robert Haas wrote:
>> After refreshing my memory further, I take it back. pg_stop_backup()
>> doesn't even have a second argument on v9.6, so back-porting this fix
>> to 9.6 is a
f
pg_stop_backup(boolean) allows for inconsistent backups, it does sound
like a problem on 9.6 too.
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
re important for partitions not to be so noisy.
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks Tom. This showed up in a regression test of ours that built the test
data using generate_series, so it's not a critical production issue or
anything, just a surprise change in behaviour.
P.
On Wed, May 24, 2017 at 10:28 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > Th
The behaviour of generate_series seems to have changed a little, at least
in conjunction w/ CTEs. Under 9.6 (and prior) this query returns 2127 rows,
with no nulls:
with
ij as ( select i, j from generate_series(1, 10) i, generate_series(1, 10)
j),
iijj as (select generate_series(1, i) as a, genera
correct, so returning NEW or OLD above seems confusing, and
likely a copy/paste error.
This patch just removes those three lines from the example code.
Thanks!
Paul
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index a6088e9..dc29e7c 100644
--- a/doc/src/sgml/plpgsql.sgml
++
On Wed, Jan 11, 2017 at 4:29 PM, Josh Berkus wrote:
>
> For that reason, as of today, I am stepping down from the PostgreSQL
> Core Team.
>
Massive thanks Josh, you've been a great advocate and a wonderful bridge
into the PgSQL community for those of us finding our way towards the warm
centre of
On Sun, Nov 27, 2016 at 11:50 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
> >> Why doesn't hs_fdw.h have a collation?
>
> > I think I'm missing something, I cannot find a file like that anywhere.
>
&g
On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey >
> > wrote:
> >> I've been trying to figure out an issue with operators not being pushed
> >> down for user defined types, in th
On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey
wrote:
> I've been trying to figure out an issue with operators not being pushed
> down for user defined types, in this case "hstore". TL;DR:
>
> hstore=# explain (verbose) select * from
I've been trying to figure out an issue with operators not being pushed
down for user defined types, in this case "hstore". TL;DR:
hstore=# explain (verbose) select * from hs_fdw where h -> 'a' = '1';
QUERY PLAN
xslt transformation is a very efficient way to
achieve that.
So, as far as I'm concerned, xslt transformation appears to be a missing
fuctionnality in the newer api.
Best regards,
Jean-Paul
--
Jean-Paul JORDA
Centre de ressources technologiques
Coordinateur de l'équipe des dévelo
ld
be implemented more accurately.
The code for pg_usleep() could be similar like this:
while(nanosleep(&req,&req)==-1 && errno == EINTR)
continue;
or combine with clock_gettime() to control the sleep time more accurately.
Regards,
Paul
On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby wrote:
> On 6/1/16 10:03 AM, Paul Ramsey wrote:
>>
>> We don't depend on these, we have our own :/
>> The real answer for a GIS system is to have an explicit tolerance
>> parameter for calculations like distance/touching/c
On Wed, Jun 1, 2016 at 7:52 AM, Jim Nasby wrote:
>
> I suspect another wrinkle here is that in the GIS world a single point can
> be represented it multiple reference/coordinate systems, and it would have
> different values in each of them. AIUI the transforms between those systems
> can be rathe
On Fri, Apr 22, 2016 at 11:44 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
>> > Would you agree that it'd be helpful to have for making the st_union()
>> >
On Tue, Apr 26, 2016 at 6:40 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 26 April 2016 at 14:06, 陈天舟 wrote:
>>> (1) Since each protocol buffer column requires a schema. I am not sure
>>> where is the best place to store that schema info. Should it be in a
>>> CONSTRAINT (but I am not able t
On Fri, Apr 8, 2016 at 9:06 AM, Simon Riggs wrote:
> On 8 April 2016 at 17:00, Paul Ramsey wrote:
>>
>> On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas wrote:
>> > On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila
>> > wrote:
>> >> Other than that, patch
On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas wrote:
> On Fri, Apr 8, 2016 at 1:22 AM, Amit Kapila wrote:
>> Other than that, patch looks good and I have marked it as Ready For
>> Committer. Hope, we get this for 9.6.
>
> Committed. I think this is likely to make parallel query
> significantly mo
On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey wrote:
> On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey
> wrote:
>
>>> On the join case, I wonder if it's possible that _st_intersects is not
>>> marked parallel-safe? If that's not the problem, I don't ha
On Tue, Mar 29, 2016 at 1:14 PM, Robert Haas wrote:
> On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey
> wrote:
>>> I have no idea why the cost adjustments that you need are different
>>> for the scan case and the aggregate case. That does seem problematic,
>>&g
On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey wrote:
>> On the join case, I wonder if it's possible that _st_intersects is not
>> marked parallel-safe? If that's not the problem, I don't have a
>> second guess, but the thing to do would be to figure out whether
> First, I beg to differ with this statement: "Some of the execution
> results output are wrong! " The point is that
> line has loops=4, so as in any other case where loops>1, you're seeing
> the number of rows divided by the number of loops. It is the
> *average* number of rows that were pro
On Mon, Mar 28, 2016 at 9:18 AM, Paul Ramsey wrote:
> Parallel join would be a huge win, so some help/pointers on figuring
> out why it's not coming into play when our gist operators are in
> effect would be helpful.
Robert, do you have any pointers on what I should look for to
On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost wrote:
> Paul,
>
> * Paul Ramsey (pram...@cleverelephant.ca) wrote:
>> I spent some time over the weekend trying out the different modes of
>> parallel query (seq scan, aggregate, join) in combination with PostGIS
>> and
I spent some time over the weekend trying out the different modes of
parallel query (seq scan, aggregate, join) in combination with PostGIS
and have written up the results here:
http://blog.cleverelephant.ca/2016/03/parallel-postgis.html
The TL:DR; is basically
* With some adjustments to functio
On Sun, Mar 13, 2016 at 7:31 PM, David Rowley
wrote:
> On 14 March 2016 at 14:52, James Sewell wrote:
>> One question - how is the upper limit of workers chosen?
>
> See create_parallel_paths() in allpaths.c. Basically the bigger the
> relation (in pages) the more workers will be allocated, up un
re the next step here. Do I click "Move to next CF" in the
"Status" dropdown? Apologies for not being familiar with the protocol.
I'd be sad to see this work just get ignored.
Thanks,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Thank the Maker, it is reproduceable: returning an expanded header in the _in
function is not appreciated in a very narrow number of cases.
Edit arrayfuncs.c:array_in(), change the return line thus:
// PG_RETURN_ARRAYTYPE_P(retval);
PG_RETURN_DATUM(expand_array(PointerGetDatum(re
papered over things so much that valgrind couldn’t see what
was going on under the covers.
Thanks!
P
> On Jan 18, 2016, at 8:36 AM, Tom Lane wrote:
>
> Paul Ramsey writes:
>> So, I've added support for converting postgis in-memory objects into
>> expanded outputs
I'm starting to think this might not actually be my mistake, but be a
very narrow issue w/ the expanded object code.
So, I've added support for converting postgis in-memory objects into
expanded outputs, and have overwritten the usual
lwgeom_to_gserialized() function with one that creates an expan
I've been working through the expanded object code to try and get a
demonstration of it working with PostGIS (still having some problems,
but it's a learning experience). On an unrelated from, I noticed in
the array expanded code, that the array code is managing its own copy
of a cache of the flat
for picking this up! I'm sorry I was not able to work on it
the last few months. I'm very glad to see someone wrapping it up. I'm
not a reviewer, but personally it looks like a good change to me.
Happy holidays,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers
On December 21, 2015 at 2:33:56 AM, Haribabu Kommi (kommi.harib...@gmail.com)
wrote:
Yes the query is producing more groups according to the selectivity.
For example - scan selectivity - 40, the number of groups - 400
Following is the query:
SELECT tenpoCord,
SUM(yokinZandaka) AS yokinZa
On Thu, Dec 10, 2015 at 10:42 PM, Haribabu Kommi
wrote:
>
> Here I attached a POC patch of parallel aggregate based on combine
> aggregate patch. This patch contains the combine aggregate changes
> also. This patch generates and executes the parallel aggregate plan
> as discussed in earlier thread
On Wed, Dec 2, 2015 at 1:55 PM, Robert Haas wrote:
> Oops. The new version I've attached should fix this.
I've been trying to see if parallel join has any effect on PostGIS
spatial join queries, which are commonly CPU bound. (My tests [1] on
simple parallel scan were very positive, though quite
The attached patch changes web references to PostGIS to point to the actual
community site (postgis.net) which is active, rather than the historical site
(postgis.org).
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
postgis_doc.patch
Description: Binary data
--
Sent via
Thanks everyone for the held and feedback on this patch!
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
On November 3, 2015 at 3:47:37 PM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Robert Haas writes:
> On Tue, Nov 3, 2015 at 2:57 PM, Tom Lane wrote:
>> Paul Ramse
On Tue, Oct 6, 2015 at 8:52 AM, Andres Freund wrote:
> I think it'd be good to add a test exercising two servers with different
> extensions marked as shippable.
Done,
P
20151006b_postgres_fdw_extensions.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Tue, Oct 6, 2015 at 6:55 AM, Andres Freund wrote:
> On 2015-10-06 06:42:17 -0700, Paul Ramsey wrote:
>> *sigh*, no you’re not missing anything. In moving to the cache and
>> marking things just as “shippable” I’ve lost the test that ensures
>> they are shippable for thi
On October 6, 2015 at 6:32:36 AM, Andres Freund
(and...@anarazel.de(mailto:and...@anarazel.de)) wrote:
> On 2015-10-06 06:28:34 -0700, Paul Ramsey wrote:
> > +/*
> > + * is_shippable
> > + * Is this object (proc/op/type) shippable to foreign server?
> > + * Chec
On Tue, Oct 6, 2015 at 5:32 AM, Andres Freund wrote:
> The problem is basically that cache invalidations can arrive while
> you're building new cache entries. Everytime you e.g. open a relation
> cache invalidations can arrive. Assume you'd written the code like:
> You're avoiding that by only e
On October 4, 2015 at 9:56:10 PM, Michael Paquier
(michael.paqu...@gmail.com(mailto:michael.paqu...@gmail.com)) wrote:
> On Sun, Oct 4, 2015 at 11:40 AM, Paul Ramsey wrote:
> > I put all changes relative to your review here if you want a nice colorized
> > place to chec
Andres,
Thanks so much for the review!
I put all changes relative to your review here if you want a nice colorized
place to check
https://github.com/pramsey/postgres/commit/ed33e7489601e659f436d6afda3cce28304eba50
On October 3, 2015 at 8:49:04 AM, Andres Freund (and...@anarazel.de) wrote:
> +
On September 30, 2015 at 3:32:21 PM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
OK. Once you can get a new patch done with a reworked
extractExtensionList, I'll get a new look at it in a timely fashion
and then let's move it to a committer's hands.
Done and thanks!
P
--
http://po
On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
> Hm. Wouldn't it be just fine if only the server is able to define a
> list of extensions then? It seems to me that all the use-cases of this
> feature require to have a list of exte
On September 30, 2015 at 12:54:44 AM, Michael Paquier
(michael.paqu...@gmail.com) wrote:
>> +extern bool extractExtensionList(char *extensionString,
>> + List **extensionOids);
>> What's the point of the boolean status in this new routine? The return
>> value of extractExtensionList is never
On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier
wrote:
> On Sat, Sep 26, 2015 at 4:29 AM, Paul Ramsey wrote:
>> On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier wrote:
>> src/backend/utils/adt/format_type.c
>> +/*
>> + * This version allows a nondefault typemo
Back from summer and conferencing, and finally responding, sorry for
the delay...
On Thu, Aug 20, 2015 at 6:01 PM, Michael Paquier
wrote:
>
>
> if (needlabel)
> appendStringInfo(buf, "::%s",
> -
> format_type_with_typemod(node->consttype,
> -
> node->consttypmod));
> +
> f
p half should be okay, but if you
believe it's not I'll go with the int8_numeric approach (in three chunks
instead of two to work around signed-vs-unsigned).
Thanks,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
ll about, so I
welcome suggestions here.
Thanks again,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On August 20, 2015 at 7:21:10 AM, Tom Lane
(t...@sss.pgh.pa.us(mailto:t...@sss.pgh.pa.us)) wrote:
> I'm not sure that the situation you describe can be expected to work
> reliably; the problems are far wider than just GUC variables. If two
> different .so's are exposing broadly the same set of C
On August 20, 2015 at 2:17:31 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> On 18 August 2015 at 21:03, Paul Ramsey wrote:
>
> > So I need a way to either (a) notice when I already have a (old) copy
> > of the library loaded and avoid trying t
Hi hackers, I've been wrestling with this one for a while and gone
down a couple blind alleys, so time to ask the experts.
PostGIS has a couple things different from the extensions that live in contrib,
- it has some GUCs
- it has a versioned loadable library (postgis-2.1.so, postgis-2.2.so, etc)
Thanks so much Michael! Let me know when you have further feedback I should
incorporate.
ATB,
P.
--
http://postgis.net
http://cleverelephant.ca
On July 25, 2015 at 4:52:11 AM, Michael Paquier (michael.paqu...@gmail.com)
wrote:
On Sat, Jul 25, 2015 at 2:19 AM, Paul Ramsey wrote:
>
On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey wrote:
> Here's an updated patch that clears the cache on changes to foreign
> wrappers and servers.
Any chance one of you folks could by my official commitfest reviewer?
Appreciate all the feedback so far!
https://commitfest.postgresq
On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey wrote:
> In testing it I came across an unrelated issue which could make it
> hard for users to manage the options on their wrappers/servers
>
> fdw=# ALTER SERVER foreign_server OPTIONS ( extensions 'postgis' );
> ALTER SE
On Wed, Jul 22, 2015 at 12:19 PM, Paul Ramsey wrote:
>
> I’ll have a look at doing invalidation for the case of changes to the FDW
> wrappers and servers.
Here's an updated patch that clears the cache on changes to foreign
wrappers and servers.
In testing it I came across an u
On July 22, 2015 at 12:15:14 PM, Andres Freund (and...@anarazel.de) wrote:
It doesn't seem that unlikely that somebody does an ALTER SERVER OPTIONS
SET .. to add an extension to be shippable while connections are already
using the fdw. It'll be confusing if some clients are fast and some
others
On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey wrote:
> On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
>
> No, *not* populated first-time-through, because that won't handle any of
> the CREATE, DROP, or UPGRADE cases. It's also doing a lot of work you
On July 21, 2015 at 11:22:12 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
> So: yes to a local cache of all forwardable functions/ops, populated in full
> the first time through (does that speak maybe to using a binary search on a
> sorted list instead of a hash, since I only pay the sort price once
On July 21, 2015 at 11:07:36 AM, Tom Lane (t...@sss.pgh.pa.us) wrote:
I'm inclined to think that it's not really necessary to worry about
invalidating a per-connection cache of "is this function safe to ship"
determinations.
So: yes to a local cache of all forwardable functions/ops, populated in
On July 21, 2015 at 8:26:31 AM, Andres Freund
(and...@anarazel.de(mailto:and...@anarazel.de)) wrote:
> On 2015-07-21 17:00:51 +0200, Andres Freund wrote:
> > On 2015-07-21 07:55:17 -0700, Paul Ramsey wrote:
> > > On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote:
>
On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund wrote:
>> +
>> + /* We need this relation to scan */
>> + depRel = heap_open(DependRelationId, RowExclusiveLock);
>> +
>> + /* Scan the system dependency table for a all entries this operator */
>> + /* depends on, then iterate throug
nition (the "cube,-postgis" entry for example). If that's a
deal-breaker, I can add it too, but it felt like something that could
wait for a user to positively declare "I must have that feature!"
P.
On Fri, Jul 17, 2015 at 5:58 AM, Paul Ramsey wrote:
>
>
a proposal to add these
functions to core Postgres?
Yours,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On July 17, 2015 at 5:57:42 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> Options already exist on CREATE FOREIGN DATA WRAPPER, so it should be easy to
> support that.
>
> I'd rather add it once on the wrapper than be forced to list all the options
> on every
On July 17, 2015 at 12:49:04 AM, Simon Riggs
(si...@2ndquadrant.com(mailto:si...@2ndquadrant.com)) wrote:
> On 17 July 2015 at 01:23, Michael Paquier wrote:
>
> > > Well, as I see it there’s three broad categories of behavior available:
> > >
> > > 1- Forward nothing non-built-in (current beha
Michael, thanks so much for the review!
On July 15, 2015 at 7:35:11 PM, Michael Paquier (michael.paqu...@gmail.com)
wrote:
This patch includes some diff noise, it would be better to remove that.
Done.
- if (!is_builtin(fe->funcid))
+ if (!is_builtin(fe->funcid) &&
(!is_in_extension(fe->funcid
uppport
Synthetic pull request for easy browsing/commenting is here:
https://github.com/pramsey/postgres/pull/1
Thanks!
Paul
diff --git a/contrib/postgres_fdw/deparse.c b/contrib/postgres_fdw/deparse.c
index 81cb2b4..bbe3c9d 100644
--- a/contrib/postgres_fdw/deparse.c
+++ b/contrib
On July 8, 2015 at 1:36:49 PM, Tom Lane (t...@sss.pgh.pa.us) wrote:
Paul Ramsey writes:
>> UNION will preferentially glom onto the btree equality operator, if memory
>> serves. If that isn't also the hash equality operator, things won't work
>> pleasantly.
&
> It still says I lack the secret sauce...
> ERROR: could not implement recursive UNION
> DETAIL: All column datatypes must be hashable.
UNION will preferentially glom onto the btree equality operator, if memory
serves. If that isn't also the hash equality operator, things won't work
p
On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan wrote:
> On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey
> wrote:
>> Is it possible to make custom types hashable? There's no hook in the
>> CREATE TYPE call for a hash function, but can one be hooked up
>> somewhere
On Thu, Jun 25, 2015 at 8:06 AM, Tom Lane wrote:
> Paul A Jungwirth writes:
>> I'm interested in adding GiST support for the UUID column type
>> . . . . So I'm curious where this change would go?
> btree_gist, I'd think
Okay, thank you for your answer! I was wo
d go? The btree_gist
extension? The uuid-ossp extension? Somewhere else?
If anyone has any advice I'd be grateful to hear it.
Thanks,
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
such) as well.
There is a PostGIS-specific implementation of this concept here:
https://github.com/pramsey/postgres/blob/9.4-postgres-fdw-postgis/contrib/postgres_fdw
If the approach above sounds OK, I'll genericize my PostGIS specific code to
hand arbitrary extensions and submit a p
On 26/05/2015 19:47, Alvaro Herrera wrote:
Paul Smith wrote:
No, nothing like that. It was just running fine, and then suddenly (at 2am
on 23 May) it started throwing up loads of these errors. The DB server
wasn't even restarted at that point. It was just working fine, then suddenly
w
On 26/05/2015 16:01, Alvaro Herrera wrote:
Paul Smith wrote:
With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:
ERROR: MultiXactId 1934308693 has not been created yet -- apparent
wraparound
on doing various queries on our database. I don't think it is a wraparound -
I
On 26/05/2015 10:23, Tatsuo Ishii wrote:
It was fixed in 9.3.7.
OK.
Do you know what the bug number was or what it was called (I've tried
searching for it before posting, but found nothing which seemed to be
the same problem as ours).
Do you know whether, if we upgrade to 9.3.7/8, it wil
With PostgreSQL 9.3.5 on Ubuntu 12.04, I'm getting the error:
ERROR: MultiXactId 1934308693 has not been created yet -- apparent
wraparound
on doing various queries on our database. I don't think it is a
wraparound - I think the tuple has mistakenly decided it has a
MultiXactId related to i
I'm implementing the recheck functionality for PostGIS so we can
support it when 9.5 comes out, and came across this fun little
crasher.
This works:
select id, name from geonames order by geom <->
'SRID=4326;POINT(-75.6163 39.746)'::geometry limit 10;
This crashes (just reversing the argument or
On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas
wrote:
> In the original post on this, you mentioned that the PostGIS guys planned to
> use this to store polygons, as bounding boxes
> (http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru). Any idea
> how would that work?
Poorly, by
le
> platform for Postgres :-(. I'm sad to hear it, but certainly have
> not got the cycles personally to prevent it.
NetBSD and OpenBSD are different systems. I don’t remember if NetBSD supports
shared libraries on VAX, but that’s independent of the fact that OpenBSD
doesn’t.
t can one be hooked up
somewhere else? In an operator?
Thanks,
P
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sunday, November 24, 2013 at 4:42 PM, Tom Lane wrote:
> The real question of course is whether transaction-level caching is
> appropriate for what they're storing. If they want only statement-level
> caching then using fn_extra is often the right thing.
I'm not certain it is... we get some grea
Hi Simon,
We do the dance because it’s how we always have and don’t know any other way,
any better way. :) The usual explanation. Is there any place you can point to
that demonstrates your technique?
Thanks!
P
--
Paul Ramsey
http://cleverelephant.ca/
http://postgis.net/
On Sunday
On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane wrote:
> Paul Ramsey writes:
>> As we've added different kinds of caching, in our own project, we've banged
>> up against problems of multiple functions trying to stuff information into
>> the same pointer, and ended u
and make it my first submission to
PgSQL.
P.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thx.
Yes, am aware PLJava is a 3rd party lib, just surprised the same party hasn't
built them given they seem to be built all the way to 9.1.
My question was primarily about obtaining pgsx.mk file which is a part of the
PostgreSQL project.
Paul
From: A
owing makefile in the Postgres dist:
/lib/pgxs/src/makefiles/pgxs.mk: No such file or
directory
What do I need to do to obtain the required files, and does anybody know why,
given Postgres 9.2 is out some time, and 9.3 is in beta, why no prebuild binary
PLJavas exist for 9.2?
Thanks,
Paul
sql.org/gitweb/?p=postgresql.git;a=commit;h=c3d09b3bd23f5f65b5eb8124a3c7592dad85a50c
Many thanks to Tom and all the pgsql-hackers for all the work you do!
Paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hello,
After a discussion on IRC in #postgresql, I had a feature suggestion and it
was suggested I write it up here.
I have a large (200GB, 1.7b rows) table with a number of columns, but the
two of interest here are a hstore column, tags and a postgis geometry
column, geom.
There is a GIN index
spatial queries. Basically the workloads on things like big
spatial joins are entirely CPU bound, so they are seeing that adding
15 processors makes things 15x faster. Spatial folks would love love
love to see parallel query execution.
--
Paul Ramsey
http://cleverelephant.ca
http://postgis.net
>
>
>
1 - 100 of 326 matches
Mail list logo
