Re: [HACKERS] proposal: schema variables

but you can always do with a (id, value) as ( values (1, 'foo'), (2, 'bar'), (3, 'baz') ) select set_config('custom.value',(select value from a where id = 2),true); if you are worried about the evaluation order On 29 October 2017 at 09:51, Chris Travers wrote: > >

Re: [HACKERS] Why we lost Uber as a user

ve. Is there any theoretical obstacle which would make it impossible to teach VACUUM not to hold back the whole vacuum horizon, but just to leave a single transaction alone in case of a long-running REPEATABLE READ transaction ? -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Ava

Re: [HACKERS] Design for In-Core Logical Replication

bar > user=repuser PUBLICATION mypub; > For the pgq-like version which consider a PUBLICATION just as list of tables to subscribe, I would add CREATE SUBSCRIPTION mysub WITH CONNECTION 'dbname=foo host=bar user=repuser' PUBLICATION mypub, mypub1; ALTER SUBSCRIPTION mysub DROP PUBLICATION m

Re: [HACKERS] Column Redaction

the redaction you suggested above is to write a special type, which redacts data on output. You can even make the type output function dependent on backup role. Just make sure that users are aware that it is not really a security feature which protects against attackers. Cheers -- Hannu Krosing

Re: [HACKERS] Anonymous code block with parameters

think now is a perfect time to revisit the issue. One possible syntax would be extending WITH to somehow enable on-spot functions in addition to on-spot views WITH FUNCTION myfunc(...) RETURNS TABLE(...) LANGUAGE plpgsql AS $$ ... $$ SELECT f.* FROM myfunc(x,y,z); Cheers -- Hannu Krosing

Re: [HACKERS] Anonymous code block with parameters

for single usage +2 I just proposed the same thing in another branch of this discussion before reading this :) I guess it proves (a little) that WITH is the right place to do these kind of things ... Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability

Re: [HACKERS] Anonymous code block with parameters

On 09/18/2014 10:40 PM, Marko Tiikkaja wrote: On 2014-09-18 10:29 PM, Vik Fearing wrote: On 09/18/2014 10:16 PM, Hannu Krosing wrote: I guess it proves (a little) that WITH is the right place to do these kind of things ... I've been wanting this syntax for a few years now, so I certainly

Re: [HACKERS] Anonymous code block with parameters

On 09/19/2014 12:14 AM, Hannu Krosing wrote: On 09/18/2014 10:40 PM, Marko Tiikkaja wrote: On 2014-09-18 10:29 PM, Vik Fearing wrote: On 09/18/2014 10:16 PM, Hannu Krosing wrote: I guess it proves (a little) that WITH is the right place to do these kind of things ... I've been wanting

Re: [HACKERS] Anonymous code block with parameters

$$ ... $$ LANGUAGE plpgsql RETURNS TABLE (col1 text, col2 int4)) mydoblock; and for the parameter-taking version SELECT (DO $$ ... $$ LANGUAGE plpgsql USING (user) RETURNS int4)(username) AS usernum FROM users; Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [HACKERS] Anonymous code block with parameters

things on replicas. especially if typed session variables could hold temporary functions . DECLARE FUNCTION mytempfucntion () ... Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] PL/pgSQL 1.2

of these. And wanting them in a way that is easy to use. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] PL/pgSQL 1.2

by Pavel Or we could expand the [] descriptor from 1. to allow more options OR we could do it in SQL-ish way using like this: SELECT ... USING FRESH PLAN; Best Regards -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql

Re: [HACKERS] PL/pgSQL 1.2

On 09/04/2014 12:17 AM, Marko Tiikkaja wrote: On 2014-09-03 23:19, Hannu Krosing wrote: 1. Conditions for number of rows returned by SELECT or touched by UPDATE or DELETE - Enforcing

Re: [HACKERS] PL/pgSQL 2

is what the NoSQL crowd provides) and something like pl/proxy for scaling. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] PL/pgSQL 2

one node :) -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] PL/pgSQL 2

for SETs now. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] PL/pgSQL 2

On 09/01/2014 12:00 PM, Marko Tiikkaja wrote: On 9/1/14 11:53 AM, Hannu Krosing wrote: On 09/01/2014 11:24 AM, Andres Freund wrote: Look at the *disaster* the few minor changes in python3 were. It's now, years after, only starting to get used again. You're going to have to find a more

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 12:55 PM, Andres Freund wrote: On 2014-09-01 12:49:22 +0200, Marko Tiikkaja wrote: On 9/1/14 12:12 PM, Andres Freund wrote: On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote: On 9/1/14 11:53 AM, Hannu Krosing wrote: You're going to have to find a more gradual way of doing

Re: [HACKERS] PL/pgSQL 2

to see in plpgsql2: - Accept RECORD input, dynamic access to fields of records without resorting to hstore hacks. This is certainly my #1. Also, an easy way to tell pl/pgsql to *not* cache plans without resorting to EXECUT'ins trings would nice Cheers Hannu -- Hannu Krosing PostgreSQL

Re: [HACKERS] On partitioning

On 09/01/2014 05:52 PM, Andres Freund wrote: On 2014-08-29 20:12:16 +0200, Hannu Krosing wrote: It would need to replace plain tid (pagenr, tupnr) with triple of (partid, pagenr, tupnr). Cross-partition indexes are especially needed if we want to allow putting UNIQUE constraints on non

Re: [HACKERS] On partitioning

, PARTITION_FUNCTION=default_range_partitioning(int) ); and then force these when adding inherited tables (in this case partition tables) either via CREATE TABLE or ALTER TABLE Best Regards -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability

Re: [HACKERS] On partitioning

on non-partition-key columns. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [HACKERS] On partitioning

partitions doesn't seem so bad). Discussing with users of other DBMSs partitioning feature, one useful phrase is TABLE xyz PARTITION FOR value. Or more generally TABLE xyz PARTITION FOR/WHERE col1=val1, col2=val2, ...; Cheers -- Hannu Krosing PostgreSQL Consultant Performance

Re: [HACKERS] jsonb format is pessimal for toast compression

-increasing series of integer offsets. How hard and how expensive would it be to teach pg_lzcompress to apply a delta filter on suitable data ? So that instead of integers their deltas will be fed to the real compressor -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules

or other odd places. Another possible answer is to just throw a not implemented error; but that doesn't seem terribly helpful, and I think it wouldn't save a lot of code anyway. Thoughts? regards, tom lane -- Hannu Krosing PostgreSQL Consultant Performance, Scalability

Re: [HACKERS] UPDATE SET (a,b,c) = (SELECT ...) versus rules

On 06/17/2014 11:22 AM, Vik Fearing wrote: On 06/17/2014 09:43 AM, Hannu Krosing wrote: On 06/14/2014 09:35 PM, Tom Lane wrote: As I mentioned awhile ago, I'm thinking about implementing the SQL-standard construct UPDATE foo SET ..., (a,b,...) = (SELECT x,y,...), ... I've run

Re: [HACKERS] RETURNING PRIMARY KEY syntax extension

[]%29 [4] http://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#execute(java.lang.String,%20java.lang.String[]) http://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#execute%28java.lang.String,%20java.lang.String[]%29 -- Hannu Krosing PostgreSQL Consultant Performance

Re: [HACKERS] RETURNING PRIMARY KEY syntax extension

On 06/10/2014 11:02 AM, Tom Dunstan wrote: On 10 June 2014 17:49, Hannu Krosing ha...@2ndquadrant.com mailto:ha...@2ndquadrant.com wrote: RETURNING GENERATED KEYS perhaps, but then how do we determine that? What about RETURNING CHANGED FIELDS ? Might be quite complicated

Re: [HACKERS] RETURNING PRIMARY KEY syntax extension

, and not for example generated alternate keys ? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] json casts

of using ISO 8601 date representation is a better solution. Just make sure you get the TZ part right - this is another place where PostgreSQL often differs from other systems' understanding of ISO timestamps. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [HACKERS] Priority table or Cache table

On 05/26/2014 04:16 PM, Fujii Masao wrote: On Sun, May 25, 2014 at 6:52 PM, Hannu Krosing ha...@2ndquadrant.com wrote: On 05/20/2014 01:46 PM, Fujii Masao wrote: On Mon, Mar 17, 2014 at 1:16 PM, Haribabu Kommi kommi.harib...@gmail.com wrote: ... I Implemented a proof of concept patch to see

Re: [HACKERS] Priority table or Cache table

it is best to be in the database, at least to get started. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Considerer Harmful Considered Harmful categorized as Mostly Harmless

categorize it as Mostly Harmless :) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] 9.4 Proposal: Initdb creates a single table

? we could expose it something like next_uuid(version nr); As the article points out Since the identifiers have a finite size, it is possible for two differing items to share the same identifier. so it is a known limitation of UUID and not something PostgreSQL specific. Cheers -- Hannu Krosing

Re: [HACKERS] 9.4 Proposal: Initdb creates a single table

with Postgres sample data in it, but that seems a step too far. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

On 04/17/2014 10:39 PM, Andres Freund wrote: On 2014-04-17 13:33:27 -0700, Peter Geoghegan wrote: Just over 99.6% of pages (leaving aside the meta page) in the big 10 GB pgbench_accounts_pkey index are leaf pages. What is the depth of b-tree at this percentage ? Cheers Hannu -- Sent via

Re: [HACKERS] AXLE Plans for 9.5 and 9.6

usefulness is probably better planning and better performance of FDW interface. So instead of integrating one specific FDW it would make sense to improve postgresql so that it can use (properly written) FDWs at native speeds Regards -- Hannu Krosing PostgreSQL Consultant Performance, Scalability

Re: [HACKERS] AXLE Plans for 9.5 and 9.6

On 04/22/2014 02:04 PM, Simon Riggs wrote: On 22 April 2014 00:24, Josh Berkus j...@agliodbs.com wrote: On 04/21/2014 03:41 PM, Simon Riggs wrote: Storage Efficiency * Compression * Column Orientation You might look at turning this: http://citusdata.github.io/cstore_fdw/ ... into a more

Re: [HACKERS] DISCARD ALL (Again)

On 04/18/2014 01:38 AM, Fabrízio de Royes Mello wrote: On Thu, Apr 17, 2014 at 6:51 PM, Alvaro Herrera alvhe...@2ndquadrant.com mailto:alvhe...@2ndquadrant.com wrote: It does sounds a legitimate feature request to me. I don't remember if we honored the request to add resetting of

Re: [HACKERS] DISCARD ALL (Again)

-- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] Question about optimising (Postgres_)FDW

On 04/16/2014 01:35 PM, Etsuro Fujita wrote: (2014/04/16 6:55), Hannu Krosing wrote: ... Maybe I'm missing something, but I think that you can do what I think you'd like to do by the following procedure: No, what I'd like PostgreSQL to do is to 1. select the id+set from local table 2. select

Re: [HACKERS] Question about optimising (Postgres_)FDW

On 04/16/2014 03:16 PM, Hannu Krosing wrote: On 04/16/2014 01:35 PM, Etsuro Fujita wrote: (2014/04/16 6:55), Hannu Krosing wrote: ... Maybe I'm missing something, but I think that you can do what I think you'd like to do by the following procedure: No, what I'd like PostgreSQL to do

[HACKERS] Question about optimising (Postgres_)FDW

? If not, how hord would it be to add this feature ? -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org

Re: [HACKERS] Question about optimising (Postgres_)FDW

On 04/16/2014 01:25 AM, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com writes: Is there a way to force it to prefer a plan where the results of (select id from onemillion where data '0.9' limit 100) are passed to FDW as a single IN ( = ANY(...)) query and are retrieved all at once

Re: [HACKERS] Question about optimising (Postgres_)FDW

On 04/16/2014 06:12 AM, Hannu Krosing wrote: On 04/16/2014 01:25 AM, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com writes: Is there a way to force it to prefer a plan where the results of (select id from onemillion where data '0.9' limit 100) are passed to FDW as a single IN ( = ANY

Re: [HACKERS] Autonomous Transaction (WIP)

On 04/09/2014 08:44 AM, Pavan Deolasee wrote: On Wed, Apr 9, 2014 at 11:03 AM, Rajeev rastogi rajeev.rast...@huawei.com mailto:rajeev.rast...@huawei.com wrote: Though autonomous transaction uses mixed approach of sub-transaction as well as main transaction, transaction state of

Re: [HACKERS] json(b) equality rules

On 04/03/2014 04:32 AM, Oleg Bartunov wrote: Hi there, I'm wondering if we should follow all js equility rules as nicely visualized in http://strilanc.com/visualization/2014/03/27/Better-JS-Equality-Table.html Probably not as JSON is general interchange format. If somebody wants JavaScript

Re: [HACKERS] GSoC proposal - make an unlogged table logged

the table contents appear on slave servers. If you don't consider replication then it might seem easier. So switch on logging and then perform CLUSTER/VACUUM FULL ? Should this work, or is something extra needed ? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [HACKERS] jsonb and nested hstore

On 02/26/2014 09:17 AM, Christophe Pettus wrote: On Feb 25, 2014, at 1:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote: It is not in any specs, but nevertheless all major imlementations do it and some code depends on it. I have no doubt that some code depends on it, but all major

Re: [HACKERS] jsonb and nested hstore

On 02/26/2014 07:41 PM, Josh Berkus wrote: On 02/26/2014 07:02 AM, Merlin Moncure wrote: On Tue, Feb 25, 2014 at 3:57 PM, Hannu Krosing ha...@2ndquadrant.com wrote: It is not in any specs, but nevertheless all major imlementations do it and some code depends on it. IIRC, this behaviour

Re: [HACKERS] jsonb and nested hstore

only by json and not by jsonb. Merlin: We should present them side-by-side with a complex comparison. Robert: Josh wants to junk all relational data and use only jsonb! I mean, really, WTF? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability

Re: [HACKERS] WAL Rate Limiting

`maintenance_wal_rate_limit_delay` same way as we have `maintenance_work_mem` Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

Re: [HACKERS] Ctrl+C from sh can shut down daemonized PostgreSQL cluster

would have thought it was running independently of my terminal and shell. In this case maybe it is pg_ctl which should do the deamoinizing ? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] jsonb and nested hstore

didn't we attach a version code to the json type send function? JSON is supposed to be a *standard* way of encoding data in strings. If the ever changes, it will not be JSON type anymore. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant

Re: [HACKERS] jsonb and nested hstore

On 02/05/2014 06:48 PM, Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: On 02/05/2014 11:40 AM, Tom Lane wrote: switching to binary is the same as text may well be the most prudent path here. If we do that we're going to have to live with that forever, aren't we? Yeah, but the

Re: [HACKERS] jsonb and nested hstore

as this is one type where we may want add type-specific compression options at some point Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] jsonb and nested hstore

is not terribly huge here and hstore might still want to develop independently. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] Standalone synchronous master

dev cycle to argue about it. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

seems to be driven from the keeping-vm-clean side it guess it will be far from simple. Cheers, Dave. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

inside postgresql. Maybe in background writer. Question to LKM folks - will kernel react well to frequent changes to /proc/sys/vm/dirty_* ? How frequent can they be (every few second? every second? 100Hz ?) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 01/15/2014 12:16 PM, Hannu Krosing wrote: On 01/14/2014 06:12 PM, Robert Haas wrote: This would be pretty similar to copy-on-write, except without the copying. It would just be forget-from-the-buffer-pool-on-write. +1 A version of this could probably already be implement using

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 01/15/2014 02:01 PM, Jan Kara wrote: On Wed 15-01-14 12:16:50, Hannu Krosing wrote: On 01/14/2014 06:12 PM, Robert Haas wrote: This would be pretty similar to copy-on-write, except without the copying. It would just be forget-from-the-buffer-pool-on-write. +1 A version of this could

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

better with postgresql by having a bit more information for its decisions. We just don't want to re-implement it ;) -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] [Lsf-pc] Linux kernel impact on PostgreSQL performance

been able to avoid it and still have reasonable performance. What was been pointed out above are some (allegedly desktop/mobile influenced) decisions which broke good performance. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

On 01/14/2014 09:39 AM, Claudio Freire wrote: On Tue, Jan 14, 2014 at 5:08 AM, Hannu Krosing ha...@2ndquadrant.com wrote: Again, as said above the linux file system is doing fine. What we want is a few ways to interact with it to let it do even better when working with postgresql by telling

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

safety. A database system worth its name must make sure that all data reported as stored to clients is there even after crash. Write ahead log is the means for that. And writing wal files and data pages has to be in certain order to guarantee consistent recovery after crash. -- Hannu Krosing

Re: [HACKERS] Standalone synchronous master

) 'syncrep_taking_too_long_command' will very likely also not reach the monitor daemon, so it can not relay on this as main trigger! Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

be placed. It may make sense to put them there based on when they were last read while residing inside postgresql cache Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Disallow arrays with non-standard lower bounds

;) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] Standalone synchronous master

and driver can manage using the right LSNs. That is the last LSN received from master is always attached to queries on slaves. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] Standalone synchronous master

Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] Standalone synchronous master

there are probably other scenarios where users are willing to trade latency for improved and/or directed durability but not at the extent of availability, don't you? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via

Re: [HACKERS] Standalone synchronous master

sync standby failing. And they actually run more than one standby, they just want to make sure that sync rep to 2nd data center always happens. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing

Re: [HACKERS] Standalone synchronous master

of disk failure :) Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] Standalone synchronous master

is always mirrored on two servers) and availability (if one server goes down, another server continues full service). What you describe is most like A-sync rep. Sync rep makes sure that data is always replicated before confirming to writer. Cheers -- Hannu Krosing PostgreSQL Consultant

Re: [HACKERS] Standalone synchronous master

for that *if configured correctly*. *But* for relying on this, we would also need to make logging *synchronous*, which would probably not go down well with many people, as it makes things even more fragile from availability viewpoint (and slower as well). Cheers -- Hannu Krosing PostgreSQL Consultant

Re: [HACKERS] Standalone synchronous master

On 01/09/2014 04:15 PM, MauMau wrote: From: Hannu Krosing ha...@2ndquadrant.com On 01/09/2014 01:57 PM, MauMau wrote: Let me ask a (probably) stupid question. How is the sync rep different from RAID-1? When I first saw sync rep, I expected that it would provide the same guarantees as RAID

Re: [HACKERS] nested hstore patch

into how hard it would be to add method notation to postgreSQL, so that instead of calling getString(hstorevalue, n) we could use hstorevalue.getString(n) -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

Rowley -- Ants Aasma -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] [PATCH] Add transforms feature

to add (use_transforms=off) It is much easier than debugging/rewriting the function, but this is something I'd like us to be able to avoid. PS. maybe we could resurrect the WITH (attribute, ...) available in CREATE FUNCTION syntax for passing function-specific flags ? Cheers -- Hannu Krosing

Re: [HACKERS] ANALYZE sampling is too good

that way that doesn't introduce bias? Initially/experimentally we could just compare it to our current approach :) That is, implement *some* block sampling and then check it against what we currently have. Then figure out the bad differences. Rinse. Repeat. Cheers -- Hannu Krosing PostgreSQL

Re: [HACKERS] [PATCH] Add transforms feature

skulpt and pyjamas which compile python source code to JavaScript VM and inherit all the sandboxing of v8. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] [PATCH] Add transforms feature

in the target pl language in addition to C. I'll see if I can resurrect my patch for support of cstring and internal types in pl/python function defs for this. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql

Re: [HACKERS] [PATCH] Add transforms feature

be calling a pl/v8 function from pl/python and converting directly between integers in both, without going through PostgreSQL type. Another and maybe even more interesting would be automatic null-transforms between two pl/python functions. Cheers -- Hannu Krosing PostgreSQL Consultant Performance

Re: [HACKERS] [PATCH] Add transforms feature

not what is being proposed. You mean something like CREATE FUNCTION f(i int, h1 hstore USING TRANSFORM x, h2 hstore) ... where h1 would go through transform x and 1 and h2 would use default transform ? Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High

Re: [HACKERS] additional json functionality

On 11/18/2013 06:49 PM, Josh Berkus wrote: On 11/18/2013 06:13 AM, Peter Eisentraut wrote: On 11/15/13, 6:15 PM, Josh Berkus wrote: Thing is, I'm not particularly concerned about *Merlin's* specific use case, which there are ways around. What I am concerned about is that we may have users who

Re: [HACKERS] additional json functionality

. Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] pre-commit triggers

On 11/17/2013 01:42 AM, Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com writes: I have not looked at the patch, but does it also run pre-rollback ? error in trigger - instant infinite loop. Means this needs to have some kind of recursion depth limit, like python def x(): ... return x

Re: [HACKERS] pre-commit triggers

On 11/17/2013 04:20 PM, Alvaro Herrera wrote: Hannu Krosing wrote: So it would send a network message, a signal or writing something to external file. If you're OK with a C function, you could try registering a callback, see RegisterXactCallback(). I already have an implementation doing

Re: [HACKERS] pre-commit triggers

On 11/17/2013 07:31 PM, Andres Freund wrote: On 2013-11-17 09:39:26 +0100, Hannu Krosing wrote: Besides, exactly what would you do in such a trigger? The use case would be telling another system about the rollback. Basically sending a ignore what I told you to do message But you can't rely

Re: [HACKERS] additional json functionality

On 11/17/2013 09:02 PM, David E. Wheeler wrote: On Nov 16, 2013, at 2:04 PM, Hannu Krosing ha...@2ndquadrant.com wrote: It’s still input and output as JSON, though. Yes, because JavaScript Object Notation *is* a serialization format (aka Notation) for converting JavaScript Objects to text

Re: [HACKERS] additional json functionality

-- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- 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] pre-commit triggers

andrew -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ

Re: [HACKERS] additional json functionality

On 11/16/2013 12:15 AM, Josh Berkus wrote: On 11/15/2013 02:59 PM, Merlin Moncure wrote: On Fri, Nov 15, 2013 at 4:31 PM, Hannu Krosing ha...@2ndquadrant.com wrote: I think you may be on to something here. This might also be a way opt-in to fast(er) serialization (upthread it was noted

Re: [HACKERS] additional json functionality

On 11/16/2013 10:30 PM, David E. Wheeler wrote: On Nov 16, 2013, at 12:04 PM, Hannu Krosing ha...@2ndquadrant.com wrote: Then perhaps name the new binary json as jsob (JavaScript Object Binary) or just jsobj (JavaScript Object) and keep current json for what it is, namely JavaScript Object

Re: [HACKERS] additional json functionality

and the problem is just with constructing extended json (a.k.a. processing instructions) to be used as source for specialised parsers and renderers. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list

Re: [HACKERS] nested hstore patch

On 11/14/2013 01:32 AM, David E. Wheeler wrote: On Nov 13, 2013, at 3:59 PM, Hannu Krosing ha...@2ndquadrant.com wrote: I remember strong voices in support of *not* normalising json, so that things like {a:1,a:true, a:b, a:none} would go through the system unaltered, for claimed standard

Re: [HACKERS] additional json functionality

that, though ... I think it confuses most people, similar to how storing 1+1 as processing instructions instead of just evaluationg it and storing 2 :) OTOH we are in this mess now and have to solve the backwards compatibility somehow. -- Hannu Krosing PostgreSQL Consultant Performance, Scalability

Re: [HACKERS] additional json functionality

On 11/14/2013 01:42 AM, Andrew Dunstan wrote: On 11/13/2013 07:01 PM, Hannu Krosing wrote: I guess we should not replace current JSON type with hstore based one, but add something json-like based on nested hstore instead. Well, that's two voices for that course of action. I am not really

Re: [HACKERS] additional json functionality

On 11/14/2013 04:07 PM, Merlin Moncure wrote: On Wed, Nov 13, 2013 at 6:01 PM, Hannu Krosing ha...@2ndquadrant.com wrote: I guess we should not replace current JSON type with hstore based one, but add something json-like based on nested hstore instead. Maybe call it jsdoc or jdoc or jsobj

  1   2   3   4   5   6   7   8   9   10   >