[HACKERS] Inlining functions with "expensive" parameters

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

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

4, 2017 at 4:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Paul Ramsey <pram...@cleverelephant.ca> writes: > >>> Whether I get a parallel aggregate seems entirely determined by the > number > >>> of rows, not the cost of preparing those rows. > > &

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

On Sat, Nov 4, 2017 at 10:02 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sat, Nov 4, 2017 at 4:43 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Paul Ramsey <pram...@cleverelephant.ca> writes: > >>> Whether I get a parallel aggregate seems entirely d

Re: [HACKERS] Parallel Plans and Cost of non-filter functions

Just clarifying myself a little, since I made a dumb error partway through. On Thu, Nov 2, 2017 at 10:09 AM, Paul Ramsey <pram...@cleverelephant.ca> wrote: > I'm working on a custom aggregate, that generates a serialized data > format. The preparation of the geometry before bei

[HACKERS] Parallel Plans and Cost of non-filter functions

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

Re: [HACKERS] generate_series regression 9.6->10

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 <t...@sss.pgh.pa.us> wrote: > Paul Ram

[HACKERS] generate_series regression 9.6->10

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,

Re: [HACKERS] Retiring from the Core Team

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

Re: [HACKERS] User-defined Operator Pushdown and Collations

On Sun, Nov 27, 2016 at 11:50 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Paul Ramsey <pram...@cleverelephant.ca> writes: > > On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Why doesn't hs_fdw.h have a collation? > > > I thin

Re: [HACKERS] User-defined Operator Pushdown and Collations

On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Paul Ramsey <pram...@cleverelephant.ca> writes: > > On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey <pram...@cleverelephant.ca > > > > wrote: > >> I've been trying to figure

Re: [HACKERS] User-defined Operator Pushdown and Collations

On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey <pram...@cleverelephant.ca> 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 * fro

[HACKERS] User-defined Operator Pushdown and Collations

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

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

On Wed, Jun 1, 2016 at 8:59 AM, Jim Nasby <jim.na...@bluetreble.com> 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 ca

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

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

Re: [HACKERS] Parallel Queries and PostGIS

On Fri, Apr 22, 2016 at 11:44 AM, Stephen Frost <sfr...@snowman.net> wrote: > Paul, > > * Paul Ramsey (pram...@cleverelephant.ca) wrote: >> On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost <sfr...@snowman.net> wrote: >> > Would you agree that it'd be hel

Re: [HACKERS] Protocol buffer support for Postgres

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

Re: [HACKERS] Choosing parallel_degree

On Fri, Apr 8, 2016 at 9:06 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 8 April 2016 at 17:00, Paul Ramsey <pram...@cleverelephant.ca> wrote: >> >> On Fri, Apr 8, 2016 at 8:23 AM, Robert Haas <robertmh...@gmail.com> wrote: >> > On Fri, Apr 8

Re: [HACKERS] Choosing parallel_degree

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

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 12:51 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote: > On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey <pram...@cleverelephant.ca> > wrote: > >>> On the join case, I wonder if it's possible that _st_intersects is not >>> marked pa

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 1:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 29, 2016 at 3:48 PM, Paul Ramsey <pram...@cleverelephant.ca> > wrote: >>> I have no idea why the cost adjustments that you need are different >>> for the scan case and

Re: [HACKERS] Parallel Queries and PostGIS

On Tue, Mar 29, 2016 at 12:48 PM, Paul Ramsey <pram...@cleverelephant.ca> 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

Re: [HACKERS] Parallel Queries and PostGIS

> 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

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 9:18 AM, Paul Ramsey <pram...@cleverelephant.ca> 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 o

Re: [HACKERS] Parallel Queries and PostGIS

On Mon, Mar 28, 2016 at 9:45 AM, Stephen Frost <sfr...@snowman.net> 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 combinati

[HACKERS] Parallel Queries and PostGIS

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

Re: [HACKERS] Parallel Aggregate

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 >

Re: [HACKERS] Expanded Objects and Order By

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);

[HACKERS] Expanded Objects and Order By

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

Re: [HACKERS] Expanded Objects and Order By

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 <t...@sss.pgh.pa.us> wrote: > > Paul Ramsey <pram...@cleverelephant.ca> writes: >> So, I've added support for convertin

[HACKERS] Expanded Object Header and Flat Cache

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

Re: [HACKERS] Parallel Aggregate

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

Re: [HACKERS] parallel joins, and better parallel explain

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

Re: [HACKERS] Parallel Aggregate

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

[HACKERS] [PATCH] PostGIS Doc Urls

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 <robertmh...@gmail.com> writes: > On Tue, Nov 3, 2015 at 2:57 PM, To

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Oct 6, 2015 at 6:55 AM, Andres Freund <and...@anarazel.de> 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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: >

Re: [HACKERS] [PATCH] postgres_fdw extension support

On September 30, 2015 at 7:06:58 AM, Tom Lane (t...@sss.pgh.pa.us) wrote: Paul Ramsey <pram...@cleverelephant.ca> 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

 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 -- 

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Sat, Sep 26, 2015 at 5:41 AM, Michael Paquier <michael.paqu...@gmail.com> 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 ve

Re: [HACKERS] [PATCH] postgres_fdw extension support

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, > - >

Re: [HACKERS] Extension upgrade and GUCs

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 to setup the GUC

Re: [HACKERS] Extension upgrade and GUCs

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

[HACKERS] Extension upgrade and GUCs

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,

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 pram

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Wed, Jul 22, 2015 at 12:19 PM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Thu, Jul 23, 2015 at 7:48 AM, Paul Ramsey pram...@cleverelephant.ca 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 SERVER

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 7:45 AM, Andres Freund and...@anarazel.de 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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: So, right after reading

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

On Tue, Jul 21, 2015 at 11:29 AM, Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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 pram...@cleverelephant.ca wrote: On July 17, 2015 at 5:57:42 AM, Simon Riggs (si...@2ndquadrant.com

Re: [HACKERS] [PATCH] postgres_fdw extension support

  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 behavior)

Re: [HACKERS] [PATCH] postgres_fdw extension support

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

Re: [HACKERS] [PATCH] postgres_fdw extension support

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,

[HACKERS] [PATCH] postgres_fdw extension support

Hi all, Attached is a patch that implements the extension support discussed at PgCon this year during the FDW unconference sesssion. Highlights: * Pass extension operators and functions to the foreign server * Only send ops/funcs if the foreign server is declared to support the relevant

Re: [HACKERS] Hashable custom types

On July 8, 2015 at 1:36:49 PM, Tom Lane (t...@sss.pgh.pa.us) wrote: Paul Ramsey pram...@cleverelephant.ca 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.   So… what

Re: [HACKERS] Hashable custom types

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

Re: [HACKERS] Hashable custom types

On Fri, Apr 25, 2014 at 4:54 PM, Peter Geoghegan p...@heroku.com wrote: On Fri, Apr 25, 2014 at 4:47 PM, Paul Ramsey pram...@cleverelephant.ca 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

[HACKERS] Extension support for postgres_fdw

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 patch. Thanks! Paul -- Paul Ramsey http

[HACKERS] GiST KNN Crasher

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

Re: [HACKERS] compress method for spgist - 2

On Wed, Feb 25, 2015 at 6:13 AM, Heikki Linnakangas hlinnakan...@vmware.com 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

[HACKERS] Hashable custom types

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

Re: [HACKERS] Traffic jams in fn_extra

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 great

Re: [HACKERS] Traffic jams in fn_extra

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

[HACKERS] Traffic jams in fn_extra

to handle it and make it a hash* if it's null, whatever API makes sense) so that multiple bits of code can cache state over function calls without banging into one another? flinfo-fn_extra_hash perhaps? If this sounds OK, I'd be honored to try and make it my first submission to PgSQL. P. -- Paul

Re: [HACKERS] Traffic jams in fn_extra

On Tue, Nov 19, 2013 at 7:32 PM, Tom Lane t...@sss.pgh.pa.us wrote: Paul Ramsey pram...@cleverelephant.ca 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

Re: [HACKERS] Parallel query execution

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

Re: [HACKERS] [BUGS] BUG #6379: SQL Function Causes Back-end Crash

:31pm] RhodiumToad: there's no trivial fix On Wed, Jan 4, 2012 at 11:32 AM, Paul Ramsey pram...@cleverelephant.ca wrote: One extra detail, my PostgreSQL is compiled with --enable-cassert. This is required to set off the killer function. On Wed, Jan 04, 2012 at 07:17:17PM +, pram

Re: [HACKERS] knngist - 0.8

(And, if we are going to break everything in sight, now would be a good time to think about changing typmod to something more flexible than one int32.) As someone who is jamming geometry type, spatial reference number and dimensionality into said 32bit typmod, let me say emphatically ...

Re: [HACKERS] knngist - 0.8

On Sat, Oct 16, 2010 at 10:17 AM, Peter Eisentraut pete...@gmx.net wrote: On lör, 2010-10-16 at 09:23 -0700, Paul Ramsey wrote:   (And, if we are going to break everything in sight, now would be a good time to think about changing typmod to something more flexible than one int32

Re: [HACKERS] KNNGiST for knn-search (WIP)

I'm sure whatever conclusion -hackers comes to in the end will be the best for pgsql, and I'll be supportive. But until then, let me note from the PostGIS point-of-view: sure would be great to get this in for 8.5 :) P. On Thu, Dec 31, 2009 at 4:26 AM, Greg Stark gsst...@mit.edu wrote: On Wed,

Re: [HACKERS] CLUSTER in 8.3.5 on GIST indexes loses all rows

FYI, this is not limited to PostGIS GIST, it appears to be all GIST (gid is an integer column and I have loaded btree_gist): pramsey=# create table ttt as select * from counties; SELECT pramsey=# create index gid_bix on ttt using gist (gid); CREATE INDEX pramsey=# select count(*) from ttt; count

[HACKERS] Access to Row ID information in Functions

In PostGIS, we have a problem, in that spatial operations are very costly, CPUwise. We have hit on a nifty enhancement recently, which was to recognize that when processing multiple rows, in joins or with literal argouments, for most functions of the form GeometryOperation(A, B), A (or B) tended

Re: [HACKERS] Access to Row ID information in Functions

Thanks Tom, Yes, we've discussed adding some kind of optional identity information to the object, it remains a potential course of action. Paul On Tue, Apr 1, 2008 at 2:37 PM, Tom Lane [EMAIL PROTECTED] wrote: Paul Ramsey [EMAIL PROTECTED] writes: The optimized form gets cached

Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?

. -Original Message- From: Paul Ramsey [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 01, 2007 3:58 PM To: Ale Raza; pgsql-hackers@postgresql.org Cc: John Baleja; PostGIS Development Discussion Subject: Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY? For all that Tom

Re: [HACKERS] Where to find kind code for STATISTIC_KIND GEOMETRY?

. This is it, but as Simon stated, you probably want to get the PostGIS guys involved too, so that duplicates can be sorted out. -- Paul Ramsey Refractions Research http://www.refractions.net [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ---(end

Re: [HACKERS] Modifying and solidifying contrib

definitions along for a ride in the dump process. What we really want is just the data. -- Paul Ramsey Refractions Research http://www.refractions.net [EMAIL PROTECTED] Phone: 250-383-3022 Cell: 250-885-0632 ---(end of broadcast)--- TIP 5

Re: [HACKERS] uuid type for postgres

Just an FYI: We also ended up rolling our own uuid type, against libuuid. It seems that uuid is a widespread enough concept that implementors *will* be asked to support it, moderately often. We *could* roll our own (were capable), others are not so lucky, and would have to point out

[HACKERS] $libdir and 8.0

Short bug report: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine, except that backend does not recognize this directory as a place to be searched

Re: [HACKERS] $libdir and 8.0

GUNDUZ wrote: Hi, On Wed, 18 Aug 2004, Paul Ramsey wrote: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine, except that backend does not recognize

Re: [HACKERS] $libdir and 8.0

); canonicalize_path(ret_path); } Bruce Momjian wrote: Devrim GUNDUZ wrote: Hi, On Wed, 18 Aug 2004, Paul Ramsey wrote: When installing PgSQL into a non-standard location (like /opt/foo) the configure script decides to install all the contrib libraries and plpglsq into /opt/foo/lib/postgresql. This would be fine

Re: [HACKERS] $libdir and 8.0

? --- Paul Ramsey wrote: Check this out! [EMAIL PROTECTED] bin]$ ./pg_config --pkglibdir /home/pramsey/pgtest/8.0/bin/lib/postgresql ^^^ And yet: ./port/pg_config_paths.h:#define PKGLIBDIR /home/pramsey/pgtest/8.0/lib/postgresql Could

Re: [HACKERS] $libdir and 8.0

then things would have worked. Paul Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: ... It is the actual binaries that seem to not know where $libdir is supposed to be. Where do they think it is? A useful way to check would be to strace the backend while you're executing createlang

Re: [HACKERS] $libdir and 8.0

plpgsql test [EMAIL PROTECTED] 8.0]$ Magically, everything now works :) Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: ... It is the actual binaries that seem to not know where $libdir is supposed to be. Where do they think it is? A useful way to check would be to strace the backend while

Re: [HACKERS] $libdir and 8.0

Thanks Tom, Yes, this is beta1, not the CVS tip, so all is golden. Paul Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: I started the database from /home/pramsey/pgtest/8.0/bin using ./pg_ctl start -D /home/pramsey/pgtest/8.0/data Ah-hah ... and this is 8.0beta1, right, not anything later

Re: [HACKERS] Default Locale in initdb

features of the database which only work correctly with a locale of C will not work by default. This is not new behaviour. (Why are you the only person who posts here who is nameless?) cheers andrew -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED

Re: [HACKERS] SELECT * FROM table LIMIT 1; is really slow

the upgrade to GiST? -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] PostgreSQL pre-fork speedup

. -- __ / | Paul Ramsey | Refractions Research \_ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: PostGIS dropgeometrycolumn function (Was: Re: [HACKERS] [7.4]

selectivity stats. Paul On Tuesday, February 3, 2004, at 11:00 AM, Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: In an idea world though, we would construct the thing as a view, so that when you did a CREATE TABLE that included a geometry type, you would automatically get a row

Re: [HACKERS] Multicolumn Indexing using R-Tree

Try using GiST rtree (examples in contrib), GiST supports multi-key indexes. On Tuesday, February 3, 2004, at 06:56 AM, Marcio Caetano wrote: I'm using PostgreSQL 7.3.2 and I need to create a R-Tree index that uses more than one column in a table. When I run the instruction it appears this

[HACKERS] PostGIS Integration

, February 3, 2004, at 12:06 PM, Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Oh, now I remember. The deal was not views, it was triggers. Oh, okay. You're right, we don't do triggers on system tables. But couldn't you combine a view on the system tables with storage of additional data outside

  1   2   >