[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

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

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

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

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

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

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

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

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

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

[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

[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. > > &

<    1   2