As per discussion on another thread related to using
custom scan nodes for prototype of parallel sequence scan,
I have developed the same, but directly by adding
new nodes for parallel sequence scan. There might be
some advantages for developing this as a contrib
module by using custom scan nodes,
Hi,
> From: Jim Nasby [mailto:jim.na...@bluetreble.com]
> On 12/2/14, 9:43 PM, Amit Langote wrote:
>
> >> >What are you going to do if the partitioning key has two columns of
> >> >different data types?
> >> >
> > Sorry, this totally eluded me. Perhaps, the 'values' needs some more
> > thought.
Sorry, here's the script.
On Thu, Dec 4, 2014 at 10:00 AM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita > wrote:
>
>> (2014/12/03 19:35), Ashutosh Bapat wrote:
>>
>>> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
>>> mailto:fujita.e
On Thu, Dec 4, 2014 at 9:05 AM, Etsuro Fujita
wrote:
> (2014/12/03 19:35), Ashutosh Bapat wrote:
>
>> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> This is not exactly extension of non-inheritance case. non-inheritance
>> case doesn't show tw
On Thu, Dec 4, 2014 at 12:58 PM, Simon Riggs wrote:
> On 4 December 2014 at 03:08, Fujii Masao wrote:
>
>> #1. set up and start the master and standby servers with
>> track_commit_timestamp disabled
>> #2. enable track_commit_timestamp in the master and restart the master
>> #3. run some write tr
On 4 December 2014 at 03:08, Fujii Masao wrote:
> #1. set up and start the master and standby servers with
> track_commit_timestamp disabled
> #2. enable track_commit_timestamp in the master and restart the master
> #3. run some write transactions
> #4. enable track_commit_timestamp in the standb
(2014/12/03 19:35), Ashutosh Bapat wrote:
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
This is not exactly extension of non-inheritance case. non-inheritance
case doesn't show two remote SQLs under the same plan node. May be you
can rename the label
On 3 December 2014 at 12:18, Atri Sharma wrote:
> So the planner keeps all possibility satisfying plans, or it looks at the
> possible conditions (like presence of foreign key for this case, for eg) and
> then lets executor choose between them?
I'm suggesting the planner keeps 2 plans: One with
On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera
wrote:
> Pushed with some extra cosmetic tweaks.
I got the following assertion failure when I executed pg_xact_commit_timestamp()
in the standby server.
=# select pg_xact_commit_timestamp('1000'::xid);
TRAP: FailedAssertion("!(((oldestCommitTs) !=
On Tue, Dec 2, 2014 at 1:11 PM, Robert Haas wrote:
> Basically, the case in which I think it's helpful to issue a
> suggestion here is when the user has used the table name rather than
> the alias name. I wonder if it's worth checking for that case
> specifically, in lieu of what you've done here
On 12/3/14 7:44 AM, Alvaro Herrera wrote:
> Does this mean you're happy with it now? Does make check-world pass for
> you?
Yes, it all works now.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
Hi,
The recent discussion about pipelining in the jodbc driver prompted me to look
at what it would take for libpq.
I have a proof of concept patch working. The results are even more promising
than I expected.
While it's true that many applications and frameworks won't easily benefit, it
am
On Wed, Dec 03, 2014 at 06:17:51PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote:
> >> What do you mean "reconstruct the enum"?
>
> > Capture its state at the time when IMPORT FOREIGN SCHEMA is executed.
> > Right now, if you try IMPORT
David Fetter writes:
> On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote:
>> What do you mean "reconstruct the enum"?
> Capture its state at the time when IMPORT FOREIGN SCHEMA is executed.
> Right now, if you try IMPORT SCHEMA on a foreign table with an enum in
> it, postgresql_fdw errors
Hi Joe,
> I have a need to provide a way to change a table's primary key
> columns, in the possible presence of foreign keys, and with concurrent
> use (as much as possible).
>
> The best way I have come up with is roughly:
> a. create the to-be-new-pk index concurrently
> b. "demote" the old pk t
On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote:
> David Fetter writes:
> > On Wed, Dec 03, 2014 at 05:38:47PM -0500, Tom Lane wrote:
> >> No. How would you know whether the remote side even has the enum,
> >> let alone whether it has an identical set of members? I don't see
> >> that e
David Fetter writes:
> On Wed, Dec 03, 2014 at 05:38:47PM -0500, Tom Lane wrote:
>> No. How would you know whether the remote side even has the enum,
>> let alone whether it has an identical set of members? I don't see
>> that enums are noticeably easier than the general case of
>> non-built-in
On Wed, Dec 03, 2014 at 05:38:47PM -0500, Tom Lane wrote:
> David Fetter writes:
> > I've been trying out 9.5-to-be's PostgreSQL FDW, and I noticed
> > that it doesn't seem to handle enum types. Would this be a
> > trivial fix?
>
> No. How would you know whether the remote side even has the enu
David Fetter writes:
> I've been trying out 9.5-to-be's PostgreSQL FDW, and I noticed that it
> doesn't seem to handle enum types. Would this be a trivial fix?
No. How would you know whether the remote side even has the enum,
let alone whether it has an identical set of members? I don't see
th
Folks,
I've been trying out 9.5-to-be's PostgreSQL FDW, and I noticed that it
doesn't seem to handle enum types. Would this be a trivial fix?
Repro:
Create an enum type in a 9.3 instance.
Use the type in a table.
Create a foreign server pointing to this instance.
Execute IMPORT F
On Wed, Dec 3, 2014 at 2:36 PM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Robert Haas wrote:
>> > I'm kind of disappointed that, in spite of previous review comments,
>> > this got committed with extensive use of the CommitTs naming. I think
>> > that's confusing, but it's also something t
On Tue, Dec 2, 2014 at 1:21 PM, Peter Geoghegan wrote:
> Incidentally, I think that an under-appreciated possible source of
> regressions here is that attributes abbreviated have a strong
> physical/logical correlation. I could see a small regression for one
> such case even though my cost model i
Alvaro Herrera wrote:
> Robert Haas wrote:
> > I'm kind of disappointed that, in spite of previous review comments,
> > this got committed with extensive use of the CommitTs naming. I think
> > that's confusing, but it's also something that will be awkward if we
> > want to add other data, such a
On Wed, Dec 3, 2014 at 2:09 PM, Robert Haas wrote:
> On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane wrote:
>> I would envision the planner starting out generating the first subplan
>> (without the optimization), but as it goes along, noting whether there
>> are any opportunities for join removal. At
On Wed, Dec 03, 2014 at 02:08:27PM -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Do you need to plan for every combination, where some joins are removed
> > and some are not?
>
> I would vote for just having two plans and one switch node. To exploit
> any finer grain, we'd have to hav
Heikki Linnakangas writes:
> Do you need to plan for every combination, where some joins are removed
> and some are not?
I would vote for just having two plans and one switch node. To exploit
any finer grain, we'd have to have infrastructure that would let us figure
out *which* constraints pend
On 12/03/2014 07:41 PM, Robert Haas wrote:
On Wed, Dec 3, 2014 at 12:33 PM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
However, even granting that that is a concern, so what? You *have* to
do the planning twice, or you're going to be generating a crap plan
On Wed, Dec 3, 2014 at 11:47 PM, Tom Lane wrote:
> Atri Sharma writes:
> > On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane wrote:
> >> I think the right approach for now is to emulate the GEQO precedent as
> >> closely as possible. Build all the single-relation Paths the same as
> >> now, then do a
Atri Sharma writes:
> On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane wrote:
>> I think the right approach for now is to emulate the GEQO precedent as
>> closely as possible. Build all the single-relation Paths the same as
>> now, then do a join search over all the relations, then (if we've noticed
>>
On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane wrote:
> Stephen Frost writes:
> > * Atri Sharma (atri.j...@gmail.com) wrote:
> >> Agreed, but in some cases, we could possibly make some assumptions (if
> >> there is no index, if a large fraction of table will be returned in
> scan,
> >> FunctionScan).
Atri Sharma writes:
> Does it also make sense to recalculate the costs from scratch for the
> replan? It might be, I am just asking.
The join costs would be recalculated from scratch, yes. The
single-relation Paths would already exist and their costs would not
change. Again, if you've not studi
Robert Haas wrote:
> On Mon, Dec 1, 2014 at 5:34 PM, Alvaro Herrera
> wrote:
> > I made two more changes:
> > 1. introduce newestCommitTs. Original code was using lastCommitXact to
> > check that no "future" transaction is asked for, but this doesn't really
> > work if a long-running transaction
Stephen Frost writes:
> * Atri Sharma (atri.j...@gmail.com) wrote:
>> Agreed, but in some cases, we could possibly make some assumptions (if
>> there is no index, if a large fraction of table will be returned in scan,
>> FunctionScan).
> All neat ideas but how about we get something which works i
On Wed, Dec 3, 2014 at 11:27 PM, Stephen Frost wrote:
> * Atri Sharma (atri.j...@gmail.com) wrote:
> > Agreed, but in some cases, we could possibly make some assumptions (if
> > there is no index, if a large fraction of table will be returned in scan,
> > FunctionScan).
>
> All neat ideas but how
* Atri Sharma (atri.j...@gmail.com) wrote:
> Agreed, but in some cases, we could possibly make some assumptions (if
> there is no index, if a large fraction of table will be returned in scan,
> FunctionScan).
All neat ideas but how about we get something which works in the way
being asked for befo
On Wed, Dec 3, 2014 at 11:19 PM, Tom Lane wrote:
> Atri Sharma writes:
> > Is it possible to only replan part of the plan in case of this
> > optimization? I think that we might need to only replan parts of the
> > original plan (as you mentioned, join search and above). So we could
> reuse
> >
Atri Sharma writes:
> Is it possible to only replan part of the plan in case of this
> optimization? I think that we might need to only replan parts of the
> original plan (as you mentioned, join search and above). So we could reuse
> the original plan in part and not do a lot of replanning (an ob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a need to provide a way to change a table's primary key
columns, in the possible presence of foreign keys, and with concurrent
use (as much as possible).
The best way I have come up with is roughly:
a. create the to-be-new-pk index concurrently
On Wed, Dec 3, 2014 at 12:33 PM, Tom Lane wrote:
> Stephen Frost writes:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> However, even granting that that is a concern, so what? You *have* to
>>> do the planning twice, or you're going to be generating a crap plan for
>>> one case or the other.
>
>>
On Wed, Dec 3, 2014 at 11:03 PM, Tom Lane wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> However, even granting that that is a concern, so what? You *have* to
> >> do the planning twice, or you're going to be generating a crap plan for
> >> one case or the other.
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> However, even granting that that is a concern, so what? You *have* to
>> do the planning twice, or you're going to be generating a crap plan for
>> one case or the other.
> Yeah, I don't see a way around that..
Also, it occurs to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Robert Haas writes:
> > On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane wrote:
> >> I would envision the planner starting out generating the first subplan
> >> (without the optimization), but as it goes along, noting whether there
> >> are any opportunities for
Robert Haas writes:
> On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane wrote:
>> I would envision the planner starting out generating the first subplan
>> (without the optimization), but as it goes along, noting whether there
>> are any opportunities for join removal. At the end, if it found that
>> th
On Wed, Dec 3, 2014 at 12:08 PM, Tom Lane wrote:
> I would envision the planner starting out generating the first subplan
> (without the optimization), but as it goes along, noting whether there
> are any opportunities for join removal. At the end, if it found that
> there were such opportunities
Robert Haas writes:
> On Wed, Dec 3, 2014 at 11:23 AM, Andres Freund wrote:
>> Well, the planstate tree is what determines the execution, right? I
>> don't see what would stop us from doing something like replacing:
>> PlanState *
>> ExecInitNode(Plan *node, EState *estate, int eflags)
>> {
>> ..
On Wed, Dec 3, 2014 at 11:23 AM, Andres Freund wrote:
> Well, the planstate tree is what determines the execution, right? I
> don't see what would stop us from doing something like replacing:
> PlanState *
> ExecInitNode(Plan *node, EState *estate, int eflags)
> {
> ...
> case T_NestLoop:
* Atri Sharma (atri.j...@gmail.com) wrote:
> What I am concerned about is that in this case, the option plans are
> competing plans rather than separate plans.
Not sure I follow this thought entirely.. The plans in the plancache
are competeing, but separate, plans.
> My main concern is that we m
On 2014-12-03 11:11:49 -0500, Robert Haas wrote:
> On Wed, Dec 3, 2014 at 10:56 AM, Andres Freund wrote:
> > On 2014-12-03 10:51:19 -0500, Robert Haas wrote:
> >> On Wed, Dec 3, 2014 at 4:29 AM, David Rowley wrote:
> >> > *** Method 1: Removing Inner Joins at planning time:
> >> >
> >> > *** Meth
* k...@rice.edu (k...@rice.edu) wrote:
> On Wed, Dec 03, 2014 at 10:00:26AM -0300, Alvaro Herrera wrote:
> > In my design I initially had overflow partitions too, because I
> > inherited the idea from Itagaki Takahiro's patch. Eventually I realized
> > that it's a useless concept, because you can
On Wed, Dec 3, 2014 at 10:56 AM, Andres Freund wrote:
> On 2014-12-03 10:51:19 -0500, Robert Haas wrote:
>> On Wed, Dec 3, 2014 at 4:29 AM, David Rowley wrote:
>> > *** Method 1: Removing Inner Joins at planning time:
>> >
>> > *** Method 2: Marking scans as possibly skippable during planning, an
On Mon, Dec 1, 2014 at 5:34 PM, Alvaro Herrera wrote:
> I made two more changes:
> 1. introduce newestCommitTs. Original code was using lastCommitXact to
> check that no "future" transaction is asked for, but this doesn't really
> work if a long-running transaction is committed, because asking fo
On 2014-12-03 10:51:19 -0500, Robert Haas wrote:
> On Wed, Dec 3, 2014 at 4:29 AM, David Rowley wrote:
> > *** Method 1: Removing Inner Joins at planning time:
> >
> > *** Method 2: Marking scans as possibly skippable during planning, and
> > skipping joins at execution (Andres' method)
> >
> > **
On Wed, Dec 3, 2014 at 8:32 PM, Stephen Frost wrote:
> * Atri Sharma (atri.j...@gmail.com) wrote:
> > So the planner keeps all possibility satisfying plans, or it looks at the
> > possible conditions (like presence of foreign key for this case, for eg)
> > and then lets executor choose between th
On Wed, Dec 3, 2014 at 4:29 AM, David Rowley wrote:
> *** Method 1: Removing Inner Joins at planning time:
>
> *** Method 2: Marking scans as possibly skippable during planning, and
> skipping joins at execution (Andres' method)
>
> *** Method 3: Marking scans as possibly skippable during planning
On 2014-12-03 11:30:32 +, Simon Riggs wrote:
> I guess we need an Option node. Tom and I discussed that about an aeon ago.
>
> The Option node has a plan for each situation. At execution time, we
> make the test specified in the plan and then select the appropriate
> subplan.
>
> That way we
On Wed, Dec 3, 2014 at 1:32 AM, Robert Haas wrote:
> On Fri, Nov 28, 2014 at 2:49 AM, Heikki Linnakangas
> wrote:
> > It also would be quite straightforward to write a separate tool to do
> just
> > that. Would be better than conflating pg_rewind with this. You could use
> > pg_rewind as the bas
maybe vertica's approach will be a useful example
http://my.vertica.com/docs/7.1.x/HTML/index.htm#Authoring/AdministratorsGuide/Partitions/PartitioningTables.htm
http://my.vertica.com/docs/7.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/CREATETABLE.htm
... [ PARTITION BY partition-c
* Stephen Frost (sfr...@snowman.net) wrote:
> * Atri Sharma (atri.j...@gmail.com) wrote:
> > So the planner keeps all possibility satisfying plans, or it looks at the
> > possible conditions (like presence of foreign key for this case, for eg)
> > and then lets executor choose between them?
>
> Ri
* Atri Sharma (atri.j...@gmail.com) wrote:
> So the planner keeps all possibility satisfying plans, or it looks at the
> possible conditions (like presence of foreign key for this case, for eg)
> and then lets executor choose between them?
Right, this was one of the thoughts that I had.
> So is t
On 03/12/14 15:54, Alvaro Herrera wrote:
Pushed with some extra cosmetic tweaks.
Cool, thanks!
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
Pushed with some extra cosmetic tweaks.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On 12/03/2014 11:24 AM, Andres Freund wrote:
On 2014-12-03 10:59:50 +0100, José Luis Tallón wrote:
snip]
I don't think the WAL logging would need to change much in comparison to
the current solution. We'd just add the page number to the WAL record.
The biggest advantage would be to require few
On Tue, Dec 2, 2014 at 5:44 PM, Tom Lane wrote:
> Peter Geoghegan writes:
>> On Tue, Dec 2, 2014 at 2:21 PM, Robert Haas wrote:
>>> Right, and what I'm saying is that maybe the "applicability" flag
>>> shouldn't be stored in the SortSupport object, but passed down as an
>>> argument.
>
>> But th
On Wed, Dec 03, 2014 at 10:00:26AM -0300, Alvaro Herrera wrote:
> Amit Langote wrote:
>
> > From: Robert Haas [mailto:robertmh...@gmail.com]
>
> > > What is an overflow partition and why do we want that?
> >
> > That would be a default partition. That is, where the tuples that
> > don't belong e
On 02/12/14 20:21, Andres Freund wrote:
On 2014-11-24 13:16:24 +0200, Heikki Linnakangas wrote:
To be clear: I don't think this API is very good for its stated purpose, for
implementing global sequences for use in a cluster. For the reasons I've
mentioned before. I'd like to see two changes to
On Wed, Dec 3, 2014 at 9:43 PM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Hi all,
>>
>> Since commit 5d93ce2d, the output of xmllint is checked by passing
>> --valid to it. Isn't that a regression with what we were doing for
>> pre-9.4 versions? For example, with 9.4 and older versions it
Xiaoyulei wrote:
> I put all the stack in attachment.
Not sure that this is really all that useful. At least I don't have the
patience to examine all this, and I'm not sure it contains the needed
info in the first place. If you were to ensure your build is using
-fno-omit-frame-pointer in cflags
Amit Langote wrote:
> From: Robert Haas [mailto:robertmh...@gmail.com]
> > What is an overflow partition and why do we want that?
>
> That would be a default partition. That is, where the tuples that
> don't belong elsewhere (other defined partitions) go. VALUES clause of
> the definition for su
Peter Eisentraut wrote:
> Fix whitespace
Does this mean you're happy with it now? Does make check-world pass for
you?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Michael Paquier wrote:
> Hi all,
>
> Since commit 5d93ce2d, the output of xmllint is checked by passing
> --valid to it. Isn't that a regression with what we were doing for
> pre-9.4 versions? For example, with 9.4 and older versions it is
> possible to compile man pages even if the xml spec is no
On Wed, Dec 3, 2014 at 5:00 PM, Simon Riggs wrote:
> On 3 December 2014 at 09:29, David Rowley wrote:
> > *** Method 3: Marking scans as possibly skippable during planning and
> > removing redundant join nodes at executor startup (Simon's method)
> >
> > Pros:
> > 1. The plan can be executed as
On 3 December 2014 at 09:29, David Rowley wrote:
> *** Method 3: Marking scans as possibly skippable during planning and
> removing redundant join nodes at executor startup (Simon's method)
>
> Pros:
> 1. The plan can be executed as normal if there are any foreign key triggers
> pending.
> 2. Does
On Wed, Dec 3, 2014 at 4:05 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
>
>
> On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita > wrote:
>
>> (2014/11/28 18:14), Ashutosh Bapat wrote:
>>
>>> On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
>>> mailto:fujita.ets...@lab.ntt.co.jp>>
>>> w
On Tue, Dec 2, 2014 at 8:29 AM, Etsuro Fujita
wrote:
> (2014/11/28 18:14), Ashutosh Bapat wrote:
>
>> On Thu, Nov 27, 2014 at 3:52 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>> Apart from the above, I noticed that the patch doesn't consider to
>> call ExplainForeignM
On 2014-12-03 10:59:50 +0100, José Luis Tallón wrote:
> On 12/02/2014 08:21 PM, Andres Freund wrote:
> >[snip]
> >>2. Instead of the single amdata field, make it possible for the
> >>implementation to define any number of fields with any datatype in the
> >>tuple. That would make debugging, monitor
On 12/02/2014 08:21 PM, Andres Freund wrote:
[snip]
2. Instead of the single amdata field, make it possible for the
implementation to define any number of fields with any datatype in the
tuple. That would make debugging, monitoring etc. easier.
My main problem with that approach is that it pret
On 3 December 2014 at 08:13, Robert Haas wrote:
> On Sun, Nov 30, 2014 at 12:51 PM, Tom Lane wrote:
> > Bottom line, given all the restrictions on whether the optimization can
> > happen, I have very little enthusiasm for the whole idea. I do not think
> > the benefit will be big enough to just
On 12/2/14, 9:43 PM, Amit Langote wrote:
>What is an overflow partition and why do we want that?
>
That would be a default partition. That is, where the tuples that don't belong
elsewhere (other defined partitions) go. VALUES clause of the definition for
such a partition would look like:
(a r
78 matches
Mail list logo
