On vendredi 24 mars 2017 08:14:03 CEST Ashutosh Bapat wrote:
> On Mon, Mar 20, 2017 at 8:33 PM, Ronan Dunklau
wrote:
> > On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote:
> >> On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau
> >
> > wrote:
> >> >
On lundi 20 mars 2017 15:52:03 CET Robert Haas wrote:
> On Mon, Mar 20, 2017 at 6:31 AM, Ronan Dunklau
wrote:
> > With range partitioning, we guarantee that each partition contains non-
> > overlapping values. Since we know the range allowed for each partition, it
> > is
=
Is there interest for such an optimization ?
Should we work from 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
ny of 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/ba
ding
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
to support that.
Sorry if that was not clear, 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 doc
ut to escape;
SET
ro=# copy test_bytea to '/tmp/test.csv' ;
ERROR: out of memory
DÉTAIL : Cannot enlarge string buffer containing 1073741822 bytes by 1 more
bytes.
I think pg_dump should not error out on any data which was valid upon
insertion. It seems the fix would be non-tri
ments, but
at the predicate level 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 p
-only 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.
Your FDW would then issue several CREATE FOREIGN TABLE statements, 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
&g
hink there's going to be a clean way to do this. The
> intention of the system is that the user-provided options are simply
> stored, not that the FDW author is going to use the options list to
> store their own bits and pieces.
I would do that during the IMPORT FOREIGN SCHEMA s
22b57bf322892ed6c504ba44a8b28
Clearly, we've lost the ability to test that the costs as set from the Python
API are indeed used.
But I agree that it would be better to have more flexibility in the regression
framework itself.
If this use case is too marginal to warrant such a chan
>
> > -> Seq Scan on c (never executed)
> >
> > Execution time: 0.092 ms
> >
> > (10 rows)
>
> So you're now the third person reporting problems here. Let's remove
> 'execution time' for COSTS off.
>
> I personally would even say that we should backpatch that to make
> backpatches involving regression tests less painful.
That wouldn't solve the first problem mentioned, which is that for some
regression tests one may want to test the costs themselves, which is now
impossible with the new planning time feature.
What would IMO make both 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
Description: This is a digitally signed message part.
regards, tom lane
Thank you for working on this patch, I'm not really fond of building strings
in a FDW for the core to parse them again but I don't see any other solution
to the problem you mentioned.
Similarly to what we do for the schema, we should also check that the server
in t
to the FDW being used. (Another thing the SQL committee failed to
> > think about.)
>
> Is this part of the SQL standard? What is it defined to do about
> 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.
turns the t_data field, whereas heap_form_tuple allocation returns the
address of the HeapTuple itself. Then, the datum itself has not been palloced.
Changing the HeapTupleGetDatum call for an heap_copy_tuple_as_datum fixes this
issue, but I'm not sure this the best way to do that.
The atta
Stmt's
> base.relation->schemaname should be set to NULL.
> Also, it would be nice to find a few words for "options",
> maybe explaining a potential application.
>
> Yours,
> Laurenz Albe
--
Ronan Dunklau
http://dalibo.com - http://dalibo.org
signature.asc
Description: This is a digitally signed message part.
t the
> core feature. I unfortunately don't have much time today but I am sending
> this patch either way to let people play with IMPORT SCHEMA if I don't come
> back to it before.
The regression tests fail because of a typo in pg_type.h: BOOLARRAYOID should
be defined to 1000, not 10
know what we should be doing about types located 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://dal
needed"),
relation_kinds (default to 'r', can support multiple kinds with a string 'rfv'
for tables, foreign tables and views).
I think we're drifting 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.
ommon accross FDWs.
A third solution, which I don't like but doesn't modify the SQL grammar, would
be to encode 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.
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 FOREI
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
> > > >
d of NIL, for a data modification statement that returns nothing.
> >
> > If we do keep the patch's approach, I'm inclined to rename returningList.
> > However, I more lean toward adding a separate flag to indicate the need
> > to return a complet
gt; impact. Virtually every programming language (including Perl) has good
> support for json.
>
> I'm not sure what the constraints of json that you might want to break
> are. Perhaps you'd like to specify.
I haven't followed the whole thread, but json is really restrictive on the
supported types: a hierarchical hstore could maybe support more types
(timestamp comes to mind) as its values, which is not a valid data type in the
json spec.
>
> 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.
ss micro-optimization and not bother; opinions welcome.
> (The savings is four bytes per foreign table trigger event.)
I was already 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
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
d maybe even the
table's inheritance structure. I'll look into that if the feature and the API
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.
Le vendredi 21 février 2014 16:45:20 Atri Sharma a écrit :
> On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau
wrote:
> > > I havent had a look at the patch yet since I dont have a nice editor
> >
> > right
> >
> > > now, but how do you han
gres_fdw POC 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.
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
ot be reproduced using 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
columns 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
> 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.
A
Le mardi 15 octobre 2013 09:47:31 Robert Haas a écrit :
> On Mon, Oct 14, 2013 at 5:24 PM, Kohei KaiGai 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 fe
Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit :
> 2013/10/10 Ronan Dunklau :
> 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 on
Le dimanche 6 octobre 2013 22:33:23 Kohei KaiGai a écrit :
> 2013/9/10 Ronan Dunklau :
> > 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 coul
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 eve
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-bui
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
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 w
Thank you for the tip, its done.
2013/7/26 Robert Haas :
> On Thu, Jul 25, 2013 at 11:07 AM, Ronan Dunklau wrote:
>> Hello.
>>
>> I was having trouble figuring how to use the coverage targets when
>> using an extension.
>> I am using approximatively the layou
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:
http://www.postgresql.org/mailpref
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, gcn
; I'm just wondering how to make integration tests to check when cdecimal is
> installed and when it is not.
>
> thanks,
> Szymon
>
>
> On 26 June 2013 10:12, Ronan Dunklau wrote:
>
>> The v2 patch does not work for me: regression tests for plpython fail on
&
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 use
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 tr
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
ed loop can work as intended: avoiding
a full 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
am
info by the "parameterized" 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
ntended,
since missing values are replaced by a null value in the remote statement.
What can be done 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
> Kohei KaiGai wrote:
>
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 ?
--
atever it takes to execute it only 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+0IYZ26iGsi5j
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/07/2012 18:30, Tom Lane wrote:
> Ronan Dunklau 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
ign paths using those pathkeys.
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
e foreign key will be enforced,
but as the application developer, I know that every directory will be
named after an user_id.
Allowing foreign keys on such a foreign table would allow us to describe
the model more precisely in PostgreSQL, and external tools could use
this knowledge too, even if P
57 matches
Mail list logo
