ion of the current rules?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
Suite 112, Jones Bay Wharf, 26-32 Pirrama Road, Pyrmont NSW 2009
*P *(+61) 2 8099 9000 <(+61)%202%208099%209000> *W* www.jirotech.com *F *
(+61) 2 8099 9099 <(+61)%202%2
http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
> <javascript:;>)
> To make changes to your subscription:
> ht
OK cool, thanks.
Can we remove the minimum size limit when the per table degree setting is
applied?
This would help for tables with 2 - 1000 pages combined with a high CPU
cost aggregate.
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
On Thu, Mar 17, 2016 at 5:05 AM, Julien Rouhaud
wrote:
>
> attached v3 drops the GUC part.
>
This looks good good. I do think that some threshold control would be good
in the long term - but you are right Robert it just feels strange.
Maybe once the final formula is
QUERY PLAN
---
GroupAggregate (cost=0.56..600085.92 rows=31 width=16)
Group Key: view_time_day
-> Index Only Scan using base_view_time_day_count_i_idx on base
(cost=0.56..450085.61 rows=3000 width=12)
(3 rows)
Cheers,
James Se
though. If
I run parallel agg on a table with 4 rows with 2 workers will it run on two
workers (2 rows each) or will the first one grab all 4 rows?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
On Wed, Mar 16, 2016 at 11:26 AM, Julien Rouhaud
wrote:
>
> I'm not too familiar with parallel planning, but I tried to implement
> both in attached patch. I didn't put much effort into the
> parallel_threshold GUC documentation, because I didn't really see a good
>
to get a parallel
plan for a tiny table. Any idea on why this would be David?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3
On Tue, Mar 15, 2016 at 9:32 AM, Robert Haas wrote:
>
> I kind of doubt this would work well, but somebody could write a patch
> for it and try it out.
OK I'll give this a go today and report back.
Would the eventual plan be to use pg_proc.procost for the functions from
On Tuesday, 15 March 2016, Robert Haas wrote:
>
> > Does the cost of the aggregate function come into this calculation at
> > all? In PostGIS land, much smaller numbers of rows can generate loads
> > that would be effective to parallelize (worker time much >> than
> >
On Mon, Mar 14, 2016 at 3:05 PM, David Rowley
wrote:
>
> Things to try:
> 1. alter table a add column ts_date date; update a set ts_date =
> date_trunc('DAY',ts); vacuum full analyze ts;
> 2. or, create index on a (date_trunc('DAY',ts)); analyze a;
> 3. or for
, but it currently isn't.
*/
Does this mean that even though we are aggregating in parallel, we are only
operating on one child table at a time currently?
Cheers,
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3
4 width=12)
(5 rows)
Unsure what's happening here.
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
On Mon, Mar 14, 2016 at 1:31
up Key: date_trunc('DAY'::text, pageview_start_tstamp)
-> Parallel Seq Scan on celebrus_fact_agg_1_p2015_12
(cost=0.00..743769.76 rows=4221741 width=12) (actual time=0.066..1631
.650 rows=3618887 loops=7)
One question - how is the upper limit of workers chosen?
James Sewell,
.449 ms
6 2000.599 ms
I'm pretty happy!
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
On Mo
Argh seems like a false alarm for now.
I installed 9.5 from RPM source (the other was one I had installed
previously) and the performance matched 9.6
Sorry about that, I must have *something* screwed up on the other one.
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
I've actually just tested this on 9.3 - and I get roughly the same as
9.6devel.
Now going back to make sure my 9.5 environment is sane.
Hopefully this isn't me jumping the gun.
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2
..670590.95 rows=31 width=13)
Group Key: view_time_day
-> Seq Scan on base (cost=0.00..520590.04 rows=3104 width=13)
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8
(replica with no reads or writes - until it becomes a master)
Keen to hear comments.
Cheers,
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
so it really hurts when I
do the min call on the parent table.
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
edge case
when this lock would be required in this circumstance?
No real urgency on this question, I just found it a bit strange and thought
someone might be able to shed some light.
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC
Oh,
I've just noticed something in the Commit fest post
- Reducing lock strength of trigger and foreign key DDL
Perhaps I just need to be more patient.
Cheers,
James Sewell,
Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3
a crash), can
anyone see any potential problems with this approach?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
On Wed, Feb 5
Node A could get ahead even if it has been shut down cleanly BEFORE the
promotion?
I'd always assumed if I shut down the master the slave would be at the same
point after shutdown - is this incorrect?
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
/message-id/519df910.4020...@vmware.com
Cheers,
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 *W* www.lisasoft.com *F *(+61) 3 8370 8099
, James Sewell wrote:
New patch attached. I've moved from using a boolean to an enum trivalue.
When ldapreferrals is set to something other than 0 or 1 exactly, it
just ignores the option. That's not good, I think. It should probably
be an error
I was avoiding ON_ERROR_STOP because I was using ON_ERROR_ROLLBACK, but
have just realised that if I encase my SQL in a transaction then rollback
will still happen.
Perfect!
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St
--
James Sewell,
PostgreSQL Team Lead / Solutions Architect
__
Level 2, 50 Queen St, Melbourne VIC 3000
*P *(+61) 3 8370 8000 * **W* www.lisasoft.com *F *(+61) 3 8370 8099
--
--
The contents of this email are confidential and may
=# alter table test1 owner to postgres;
ALTER TABLE
Cheers,
James Sewell
Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png]
Level 2, 50 Queen St,
Melbourne, VIC, 3000
P: 03 8370 8000 F: 03 8370 8099 W
Hey,
New patch attached. I've moved from using a boolean to an enum trivalue.
Let me know what you think.
Cheers,
James
James Sewell
PostgreSQL Team Lead / Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png
would be to have the default value (of the parameter) be
true and set the boolean to false to disable it. I can't find any other
examples of this though - I assume having a one off like this in the code
is a bad thing also?
I'm happy to let you guys decide.
Cheers,
James
James Sewell
PostgreSQL
Sewell
James Sewell
PostgreSQL Team Lead / Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1/2013hieghtslogan_0.png]
Level 2, 50 Queen St,
Melbourne, VIC, 3000
P: 03 8370 8000 F: 03 8370 8099 W: www.lisasoft.com
On Tue, Jul 2
to be the default for
ldapsearch on Linux these days.
Hopefully I found all the documentation that I was meant to update, let me
know if not though.
Cheers,
James Sewell
PostgreSQL Team Lead / Solutions Architect
_
[image:
http://www.lisasoft.com/sites/lisasoft/files/u1
33 matches
Mail list logo