On vendredi 24 mars 2017 08:14:03 CEST Ashutosh Bapat wrote:
> On Mon, Mar 20, 2017 at 8:33 PM, Ronan Dunklau <ronan.dunk...@dalibo.com>
wrote:
> > On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote:
> >> On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau <ronan.dunk...
On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote:
> On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau <ronan.dunk...@dalibo.com>
wrote:
> > With range partitioning, we guarantee that each partition contains non-
> > overlapping values. Since we know the range allow
om the patch proposed to remove parent tables already ?
Should there be a new Node for such a "SortedAppend" operation or is it fine
keeping it with the Append node already ? Should that instead be an
optimization of the MergeAppend Node ?
What is or is not acceptable with regards
the child relation ? It seems to me there could
be an advantage in using a MergeAppend of explicitly sorted relations over
sorting an Append, in particular if every existing subpath can be sorted in
work_mem.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org diff --git a/src/backend
restrictinfos for later processing since they are already special-cased later
on.
Regards,
--
Ronan Dunklau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ar, I'm at PGCon at the moment so if anyone want to
discuss that in person I'm available.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Le lundi 30 mars 2015 18:45:41 Jim Nasby a écrit :
On 3/30/15 5:46 AM, Ronan Dunklau wrote:
Hello hackers,
I've tried my luck on pgsql-bugs before, with no success, so I report
these
problem here.
The documentation mentions the following limits for sizes:
Maximum Field Size
was valid upon
insertion. It seems the fix would be non-trivial, since StringInfo structures
are relying on a limit of MaxAllocSize. Or am I missing something ?
Thank you.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
rather than statement level. It stores normalized
predicates as well as constants.
The documentation is here:
http://powa.readthedocs.org/en/latest/stats_extensions/pg_qualstats.html#pg-qualstats
It won't give you all normalized values though, only those present in
predicates.
--
Ronan Dunklau
option (similar to --roles-
only and --tablespaces-only).
Would such a patch be welcome ?
PS: this email was originally sent to the pgsql-bugs mailing list
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
, with all
the necessary options.
Or even, to allow importing multiple files at once:
IMPORT FOREIGN SCHEMA public FROM SERVER file_server INTO local_schema OPTIONS
(directory '/path/to/the/file_dir/');
Demai
On Wed, Oct 29, 2014 at 10:01 AM, Ronan Dunklau ronan.dunk...@dalibo.com
wrote
their own bits and pieces.
I would do that during the IMPORT FOREIGN SCHEMA statement. That way, the user
doesn't have to specify those options: they would be generated at IMPORT time,
and the user could change them later if really needed.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
cases suitable would be to eliminate ALL timing from
TIMING OFF, not only the timing on the individual nodes. As was mentioned
before, it is a bit counter intuitive to have COSTS OFF disable the planning
time, and not TIMING OFF.
Greetings,
Andres Freund
--
Ronan Dunklau
signature.asc
.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
non-table objects?
The OPTIONS clause is not part of the SQL Standard.
Regarding non-table objects, the standard only talks about tables, and nothing
else.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
a potential application.
Yours,
Laurenz Albe
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
for an heap_copy_tuple_as_datum fixes this
issue, but I'm not sure this the best way to do that.
The attached patch implements this.
regards, tom lane
--
Ronan Dunklau
http://dalibo.com - http://dalibo.orgdiff --git a/src/pl/plpython/expected/plpython_composite.out b/src
to it before.
The regression tests fail because of a typo in pg_type.h: BOOLARRAYOID should
be defined to 1000, not 1003 (which clashes against NAMEARRAYOID).
What do you think should be documented, and where ?
Regards,
--
Ronan Dunklau
http://dalibo.com - http://dalibo.orgFrom
in a
different schema. For example, if the remote table s1.t1 has a column of
composite type s2.typ1, should we import typ1 in s1 ? In S2, optionnaly
creating the non-existing schema ? Raise an error ?
Regards,
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description
the options in the remote_schema name.
Would one of those solutions be acceptable ?
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
further away from the standard with that kind of stuff,
but I'd be happy to implement it if that's the path we choose.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le dimanche 25 mai 2014 12:41:18 David Fetter a écrit :
On Fri, May 23, 2014 at 10:08:06PM +0200, Ronan Dunklau wrote:
Hello,
Since my last proposal didn't get any strong rebuttal, please find
attached a more complete version of the IMPORT FOREIGN SCHEMA statement.
Thanks!
Please
Le dimanche 23 mars 2014 02:44:26 Noah Misch a écrit :
On Tue, Mar 18, 2014 at 09:31:06AM +0100, Ronan Dunklau wrote:
Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit :
(1) To acquire the old tuple for UPDATE/DELETE operations, the patch
closely
parallels our handling
of returningList. Thoughts?
On Thu, Mar 06, 2014 at 09:11:19AM +0100, Ronan Dunklau wrote:
Le mercredi 5 mars 2014 22:36:44 Noah Misch a écrit :
Agreed. More specifically, I see only two scenarios for retrieving
tuples from the tuplestore. Scenario one is that we need the next
tuple
happy with having a lower footprint for foreign table trigger
events than for regular trigger events, but if we remove the need for seeking
in the tuplestore entirely, it would make sense to get rid of the index.
Thanks,
nm
Thanks to you.
--
Ronan Dunklau
http://dalibo.com - http
.
Whatever we do, rest assured your work won't go to waste.
cheers
andrew
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Hello.
Did you have time to review the latest version of this patch ? Is there
anything I can do to get this ready for commiter ?
Thank you for all the work performed so far.
Le mardi 4 février 2014 13:16:22 Ronan Dunklau a écrit :
Le lundi 3 février 2014 23:28:45 Noah Misch a écrit
for discussing the design?
--
Ronan Dunklau
http://dalibo.com - http://dalibo.orgdiff --git a/src/backend/commands/event_trigger.c b/src/backend/commands/event_trigger.c
index 024a477..40a2540 100644
--- a/src/backend/commands/event_trigger.c
+++ b/src/backend/commands/event_trigger.c
@@ -250,7 +250,8
implementation, this is done by parsing the
attributes type from the query result with the regtype input functions. The
attribute typmod is injected too.
Regards,
Atri
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
Le vendredi 21 février 2014 16:45:20 Atri Sharma a écrit :
On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau
ronan.dunk...@dalibo.comwrote:
I havent had a look at the patch yet since I dont have a nice editor
right
now, but how do you handle inter operability between datatypes
are deemed worthy.
Thank you for the review.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
the patch.
Previous concerns about using both get_pgpid and postmaster_is_alive are
adressed.
There is no regression tests covering this bugfix, althought I don't know if
it would be practical to implement them.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description
with the returned slot before calling the trigger, but I'm not really
sure how to safely perform that. Any advice ?
Many thanks to Kohei Kaigai for taking the time to help with the design.
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
test_with_postgres_fdw.sql
Description: application
Le mardi 15 octobre 2013 09:47:31 Robert Haas a écrit :
On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
And, I also want some comments from committers, not only from mine.
+1
+1
/me pokes head up. I know I'm going to annoy people with this
comment, but I
Sorry, I might call it something like primary key, instead of 'tupleid'.
Apart from whether we can uniquely identify a particular remote record with
an attribute, what FDW needs here is something to identify a remote
record. So, we were talking about same concept with different names.
Ah,
Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit :
2013/10/10 Ronan Dunklau rdunk...@gmail.com:
Sorry, I'm uncertain the point above.
Are you saying FDW driver may be able to handle well a case when
a remote tuple to be updated is different from a remote tuple being
fetched
Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
2013/9/10 Ronan Dunklau rdunk...@gmail.com:
For row-level triggers, it seems more complicated. From what I understand,
OLD/NEW tuples are fetched from the heap using their ctid (except for
BEFORE INSERT triggers). How could
On Sunday 22 September 2013 01:34:53 Peter Eisentraut wrote:
On Thu, 2013-07-25 at 17:07 +0200, Ronan Dunklau wrote:
I am using approximatively the layout that was proposed here:
http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
It looks like everything is hard-coded
On Thursday 12 September 2013 12:10:01 Peter Eisentraut wrote:
The documentation build fails:
openjade:trigger.sgml:72:9:E: end tag for ACRONYM omitted, but OMITTAG
NO was specified
openjade:trigger.sgml:70:56: start tag was here
Thank you, I took the time to install a working doc-building
On Wednesday 11 September 2013 06:27:24 Michael Paquier wrote:
As your patch is targeting the implementation of a new feature, please
consider adding this patch to the next commit fest that is going to
begin in a couple of days:
https://commitfest.postgresql.org/action/commitfest_view?id=19
I
Hello.
I wanted to know what it would take to implement triggers on foreign tables.
It seems that statement-level triggers can work provided they are allowed in
the code.
Please find attached a simple POC patch that implement just that.
For row-level triggers, it seems more complicated. From
Thank you for the tip, its done.
2013/7/26 Robert Haas robertmh...@gmail.com:
On Thu, Jul 25, 2013 at 11:07 AM, Ronan Dunklau rdunk...@gmail.com wrote:
Hello.
I was having trouble figuring how to use the coverage targets when
using an extension.
I am using approximatively the layout
Hello.
I was having trouble figuring how to use the coverage targets when
using an extension.
I am using approximatively the layout that was proposed here:
http://www.postgresql.org/message-id/51bb1b6e.2070...@dunslane.net
It looks like everything is hard-coded to take the source and the
gcda,
Please ignore this comment:
I noticed that make clean leaves gcda and gcov files on the current
HEAD, and this is no different with the given patch.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
The v2 patch does not work for me: regression tests for plpython fail on
the plpython_types test: every numeric is converted to None.
It seems the global decimal ctor is not initialized.
Please find two patches, to be applied on top of the v2 patch: one
initializes the decimal ctor, the other
tests to check when cdecimal is
installed and when it is not.
thanks,
Szymon
On 26 June 2013 10:12, Ronan Dunklau rdunk...@gmail.com wrote:
The v2 patch does not work for me: regression tests for plpython fail on
the plpython_types test: every numeric is converted to None.
It seems
Concerning the efficiency problem, it should be noted that the latest 3.3
release of cpython introduces an accelerator for decimal data types, as a
C-module. This module was previously available from the Python package
index at: https://pypi.python.org/pypi/cdecimal/2.2
It may be overkill to try
on the delete operation itself.
- in the AddForeignUpdateTargets hook, add resjunk entries for the columns in
the returning clause
- in the ExecForeignDelete hook, fill the returned slot with values taken from
the planSlot.
--
Ronan Dunklau
signature.asc
Description: This is a digitally signed message
clauses, and then adding these to the scan clauses
passed to GetForeignPlan ?
Regards,
--
Ronan Dunklau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
seqscan on the remote side.
Or is there another way to achieve the same goal ?
Regards,
--
Ronan Dunklau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to make the behaviour more consistent ?
I'm very excited about this feature, thank you for making this possible.
Regards,
--
Ronan Dunklau
2012/12/14 Albe Laurenz laurenz.a...@wien.gv.at
Kohei KaiGai wrote:
I came up with one more query that causes a problem:
[...]
This causes a deadlock
Maybe you could set some options on the foreign table before selecting from
it ?
Another way you could achieve the same result would be to give some column
a special meaning (like it is done in the twitter_fdw for example).
If you don't mind, do you have a specific use-case for this ?
--
Ronan
one
time for each distinct couple ?
Best regards,
- --
Ronan Dunklau
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAEBAgAGBQJQAEbxAAoJECTYLCgFy323FTUH/j81AAT1ODBdizIdTV+yI7nX
KjCg+hBwTlKMs8l8KUuslEo0wp3Wc8Yem0PFCvO3+0IYZ26iGsi5jIoqflaZ86gZ
MAjRoUyXfn3Maz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2012 18:30, Tom Lane wrote:
Ronan Dunklau rdunk...@gmail.com writes:
Let's say I have an IMAP foreign data wrapper, and I write a
query joining the table on itself using the In-Reply-To and
Message-ID headers, is there anything I can do
.
There was a discussion about index on foreign tables back in march.
- From what I understand from this discussion, someone proposed to
locally store information about indexes on the foreign tables, but I
did not find anything on how to build a path from scratch.
Thank you.
- --
Ronan Dunklau
conditions
between tables.
On the other hand, should foreign keys referencing a foreign table be
allowed too ? From a foreign table to another, from a local table to a
foreign table ?
Regards,
--
Ronan Dunklau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
56 matches
Mail list logo
