Qingqing Zhou wrote:
> On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby wrote:
> >
> > I think a better option would be shoving it into a backend tuplestore and
> > just leaving it there (maybe with a command to clear it for the paranoid).
> > That gives a relation you can query against, insert into ano
On Thu, Jul 30, 2015 at 2:42 PM, Jim Nasby wrote:
>
> I think a better option would be shoving it into a backend tuplestore and
> just leaving it there (maybe with a command to clear it for the paranoid).
> That gives a relation you can query against, insert into another table, etc.
> --
This is
On 7/29/15 2:40 PM, Alvaro Herrera wrote:
Qingqing Zhou wrote:
Can we simplify above with foreign table methods? There are two major
concerns about this method per previous discussions: security and
usability. I think the main cause is the sharing foreign table design.
I think foreign data wr
Qingqing Zhou wrote:
> Can we simplify above with foreign table methods? There are two major
> concerns about this method per previous discussions: security and
> usability. I think the main cause is the sharing foreign table design.
I think foreign data wrappers are great. I do not think that w
On Tue, Jul 28, 2015 at 6:13 PM, Tom Lane wrote:
> Another point is that we decided a long time ago that EXPLAIN's plain-text
> output format is not intended to be machine-parsable, and so objecting to
> a design on the grounds that it makes machine parsing harder is pretty
> wrongheaded. I'd thi
Qingqing Zhou writes:
> There are still something bothering me: EXPLAIN is a mixed output with
> original text, rows for RelOptInfo, rows for Paths and possible others
> added later. So we have to use 't as text' to receive each line. To do the
> insertion, we have to further decompose each text l
On Tue, Jul 28, 2015 at 2:43 PM, Tom Lane wrote:
>
> You can do something like that in plpgsql, for example
>
> declare t text;
>
> for t in EXPLAIN SELECT ...
> loop
>insert into whatever values(t);
> end loop;
>
I see - this is cool.
There are still something bothering
Qingqing Zhou writes:
> Not sure if I got it: so EXPLAIN will return tuples to libpq client. But
> how do we store these returned tuples (RelOptInfo, Path etc) so we can
> throw queries against them later?
> Something like this:
> INSERT INTO my_space SELECT (EXPLAIN SELECT ...); -- won't get par
On Tue, Jul 28, 2015 at 12:08 PM, Alvaro Herrera
wrote:
> I would have a tuplestore, and the planner code would push tuples to it.
> After the planning is done, EXPLAIN can read and return tuples from the
> store to the user.
>
Not sure if I got it: so EXPLAIN will return tuples to libpq client.
Alvaro Herrera writes:
> Qingqing Zhou wrote:
>> The file name is not random, it is fixed so we can create foreign table
>> once and use it afterwards - I actually want to push them into
>> system_views.sql.
> Got that. That seems fragile and not very convenient; I don't think
> forcing retries
Qingqing Zhou wrote:
> On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera
> wrote:
> >
> > I think this is a pretty neat idea, but I'm not sure this user interface
> > is a good one. Why not have a new option for EXPLAIN, so you would call
> > "EXPLAIN (planner_stuff=on)" and it returns this as a re
On Mon, Jul 27, 2015 at 8:20 PM, Alvaro Herrera
wrote:
>
> I think this is a pretty neat idea, but I'm not sure this user interface
> is a good one. Why not have a new option for EXPLAIN, so you would call
> "EXPLAIN (planner_stuff=on)" and it returns this as a resultset?
Thank you for the feedb
Qingqing Zhou wrote:
> Attached is a draft patch implementing the idea. To play with it, you
> shall create the follow two foreign tables:
> CREATE EXTENSION file_fdw;
> CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;
> create foreign table pg_planner_rels(rel text, content text)server
> pglog
On Thu, Jul 23, 2015 at 4:11 PM, Tatsuo Ishii wrote:
> Sounds like a great feature!
>
Thanks!
Attached is a draft patch implementing the idea. To play with it, you
shall create the follow two foreign tables:
CREATE EXTENSION file_fdw;
CREATE SERVER pglog FOREIGN DATA WRAPPER file_fdw;
create for
> Here is a proposal introducing some debugging infrastructure into the
> core. The basic idea is to allow us to query the planner search space.
> To so do, we can dump related information to csv files and use foreign
> table to query them. So here I propose two foreign tables:
Sounds like a great
On Tue, Jul 21, 2015 at 5:15 PM, Qingqing Zhou
wrote:
> Here is a proposal introducing some debugging infrastructure into the
> core. The basic idea is to allow us to query the planner search space.
> To so do, we can dump related information to csv files and use foreign
> table to query them.
FW
Here is a proposal introducing some debugging infrastructure into the
core. The basic idea is to allow us to query the planner search space.
To so do, we can dump related information to csv files and use foreign
table to query them. So here I propose two foreign tables:
create foreign table pg_p
17 matches
Mail list logo
