[HACKERS] Columnar storage support
Is there a chance that pluggable storage permits creation of a columnar rdbms as monetDB in PostgreSQL ? Thanks un advance for thé answer -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] Columnar storage support
Thanks a lot for all thoses informations regarding this "Feature" development. I'll try to test VOPS soon, and see if monetdb_fdw support filter and aggregates pushdown ;o) PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] Continuous integration on Windows?
This may seems obvious for you but where is the build result ? Is it stored somewhere to permit to users like me that want to test pg 10 on windows without having to build it ? Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] Continuous integration on Windows?
Oups what a silly boy, I didn't saw that pg10 was released ;o( That's all I need soon (to test Declarative partitioning). Thanks for taking time to answer me in a so detailled and interesting manner. Regards PAscal -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] SAP Application deployment on PostgreSQL
There is still some activities regarding this question like https://blogs.sap.com/2017/05/08/replicate-abap-database-table-definition-to-postgresql/ Maybe PG or EDB (with the Oracle compatibility layer) would have been better strategic choice for SAP to conter ORACLE ;o) -- Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html -- 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] Statement-level rollback
Hello, EDB Oracle compatibility proposes edb_stmt_level_tx parameter, psql uses ON_ERROR_ROLLBACK = 'on', ODBC has a parameter for this JDBC has nothing and developers has to play with savepoint as described http://blog.endpoint.com/2015/02/postgres-onerrorrollback-explained.html This feature (as a GUC at server level) would be very helpfull for Oracle applications migration. Regards PAscal -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948032.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- 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] Statement-level rollback
Thanks ! that's a very good new ! I'm still receiving the famous "current transaction is aborted" error when usingversion 42.0.0 with jdbc:postgresql://localhost:5432/postgres?autosave=always But I will see that with pgjdbc team ;o) Regards PAscal -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948053.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Re: [HACKERS] Statement-level rollback
There was a mistake in my driver definition, this works fine with autosave=always (but not with autoSave ...) Thanks Again De : Vladimir Sitnikov [via PostgreSQL] Envoyé : mardi 7 mars 2017 22:32:27 À : legrand legrand Objet : Re: Statement-level rollback Please disregard my previous message. pgjdbc is already doing upcase conversion, so I would like to see a test case that reproduces the error. Alternatively, could you please capture and share TRACE log? ( https://jdbc.postgresql.org/documentation/head/logging.html#configuration ) Vladimir ср, 8 мар. 2017 г. в 1:26, Vladimir Sitnikov <[hidden email]>: legrand>when usingversion 42.0.0 with legrand> jdbc:postgresql://localhost:5432/postgres?autosave=always The pitfall there is the value should be written with upper case like autosave=ALWAYS. I've filed https://github.com/pgjdbc/pgjdbc/issues/769 to improve that at some point. Vladimir If you reply to this email, your message will be added to the discussion below: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948059.html To unsubscribe from Statement-level rollback, click here<http://www.postgresql-archive.org/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5946725&code=bGVncmFuZF9sZWdyYW5kQGhvdG1haWwuY29tfDU5NDY3MjV8MjA2NDQ0Mjc1MA==>. NAML<http://www.postgresql-archive.org/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> -- View this message in context: http://www.postgresql-archive.org/Statement-level-rollback-tp5946725p5948076.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
[HACKERS] Partitionning: support for Truncate Table WHERE
Hello, Working in a DSS environment, we often need to truncate table partitions regarding a WHERE condition and have to: - query the dictionnary to identify thoses partitions, - build SQL statements, - truncate all partitions covered by the WHERE condition - eventually delete the rest ... - perform additionnal maintenance tasks Wouldn't it be possible to make it possible directly in SQL as a TRUNCATE TABLE WHERE syntax ? I have done something similar using a procedure in Oracle: - identifying partitions using oracle rowids by a SELECT using the same WHERE conditions - for each partition check if data NOT in WHERE condition - then DELETE WHERE or TRUNCATE PARTITION depending of data distribution. Maybe there are some other constrainst like locking, FK disabling/enabling, indexes rebuild ... Would be pleased to ear your feedback regarding this. Regards PAscal
Re: [HACKERS] Partitionning: support for Truncate Table WHERE
here is an exemple : CREATE OR REPLACE FUNCTION truncate_table_where(v_table VARCHAR, v_where_condition VARCHAR) RETURNS void AS $$ DECLARE v_stmt varchar; v_tableoid oid; v_part varchar; v_found_other integer; BEGIN LOOP v_stmt := 'SELECT tableoid FROM '|| v_table||' WHERE '||v_where_condition||' limit 1 '; EXECUTE v_stmt INTO v_tableoid; IF (v_tableoid is null) THEN EXIT; END IF; Select pg_namespace.nspname||'.'||pg_class.relname into v_part from pg_catalog.pg_class INNER JOIN pg_namespace ON pg_class.relnamespace = pg_namespace.oid where pg_class.oid = v_tableoid; RAISE NOTICE 'Partition found: %', v_part; -- check if other data in part v_stmt := 'SELECT 1 FROM '|| v_part||' WHERE NOT ('||v_where_condition||') limit 1 '; EXECUTE v_stmt INTO v_found_other; IF (v_found_other =1) THEN v_stmt := 'DELETE FROM '|| v_part||' WHERE '||v_where_condition; RAISE NOTICE 'Executing: %', v_stmt; EXECUTE v_stmt; ELSE v_stmt := 'TRUNCATE '|| v_part; RAISE NOTICE 'Executing: %', v_stmt; EXECUTE v_stmt; END IF; END LOOP; END $$ LANGUAGE plpgsql; ; De : Amit Langote Envoyé : mercredi 7 décembre 2016 06:58:03 À : Craig Ringer; legrand legrand Cc : pgsql-hackers@postgresql.org Objet : Re: [HACKERS] Partitionning: support for Truncate Table WHERE On 2016/12/07 15:26, Craig Ringer wrote: > On 7 December 2016 at 07:29, legrand legrand > wrote: > >> Working in a DSS environment, we often need to truncate table partitions >> regarding a WHERE condition and have to >> [...] >> Would be pleased to ear your feedback regarding this. > > It sounds like something that'd be useful to do on top of declarative > partitioning, once that is merged. Perhaps you could start by reading > and testing the declarative partitioning patch. That'll give you a > better idea of the practicalities of doing what you propose on top of > it, and give you an opportunity to suggest changes to the declarative > partitioning scheme that might make conditional truncate easier later. Agreed. If I understand the request correctly, TRUNCATE on the parent table (a partitioned table), which currently recurses to *all* child tables (partitions), should have a restricting WHERE clause, right? It would become possible to implement something like that with the new declarative partitioned tables. As Crag mentioned, you can take a look at the discussion about declarative partitioning in the emails linked to at the following page: https://commitfest.postgresql.org/12/611/ Thanks, Amit