On 9/26/09 3:00 PM, Emmanuel Cecchet wrote:
> Hi Simon,
>
> Thanks for the insight. I might take that as a long term project. I have
> to discuss that with my colleagues at Aster. It would certainly help to
> put together a wiki page with the key insights on the design of such
> implementation to
Hi Simon,
Thanks for the insight. I might take that as a long term project. I have
to discuss that with my colleagues at Aster. It would certainly help to
put together a wiki page with the key insights on the design of such
implementation to be able to better scope the project and agree on wha
Herodotos Herodotou writes:
> On Tue, Sep 22, 2009 at 8:06 PM, Jeff Davis wrote:
>> I think you mean that the planning time is in milliseconds, not seconds.
> The planning time is actually in seconds.
This is exactly why I think this is a dead-end approach. Trying to do
theorem proving from an
On Tue, 2009-09-22 at 18:16 -0400, Emmanuel Cecchet wrote:
> If the partitioning implementation does not make progress (and does not
> make it for 8.5)
Manu, not sure if you are referring to Kedar's patch I reviewed earlier
in July, but that patch didn't implement anything like the right
intern
Hi Jeff,
On Tue, Sep 22, 2009 at 8:06 PM, Jeff Davis wrote:
> I think you mean that the planning time is in milliseconds, not seconds.
>
The planning time is actually in seconds. Even without our feature,
planning takes a few seconds since the optimizer deals with hundreds
or even thousands of c
> If it could be done with a small amount of throwaway
> code, maybe ...
Well, that's a reasonable goal ...
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
Josh Berkus writes:
> I don't think that waiting for our plans for a more robust partitioning
> implementation is a reason to put off improvements to the implementation
> we have.
The complaint I had was that this patch consisted largely of code that
we'd want to throw away once a better partitio
> As I understand it, partitioning will certainly lead to some significant
> changes/enhancements to the planner. Do you think it is realistic to get
> that for 8.5?
I don't think that waiting for our plans for a more robust partitioning
implementation is a reason to put off improvements to the i
On Tue, 2009-09-22 at 18:16 -0400, Emmanuel Cecchet wrote:
> If the partitioning implementation does not make progress (and does not
> make it for 8.5), don't you think that this could be an interesting
> contribution to consider for this release?
> I have put on the wiki
> (http://wiki.postgres
Tom,
If the partitioning implementation does not make progress (and does not
make it for 8.5), don't you think that this could be an interesting
contribution to consider for this release?
I have put on the wiki
(http://wiki.postgresql.org/wiki/Join_optimization_for_inheritance_tables)
the res
Herodotos Herodotou writes:
> This patch extends the query optimizer to consider joins between child tables
> when hierarchies are joined together.
I looked over this patch a bit. I am of the opinion that this is a lot
of work towards a dead-end direction :-(. The patch contains a large
amount
Herodotos Herodotou escreveu:
> This patch extends the query optimizer to consider joins between child tables
> when hierarchies are joined together.
>
> Short description: when the optimizer considers join paths between two tables
> with child tables, it only creates join paths over two append
On Mon, Jul 6, 2009 at 10:23 PM, Nedyalko Borisov wrote:
> For example, typical observed scenario is: optimizer chooses Merge Join for
> two partitioned tables like the plan below:
> Merge Cond: (table1.id = table2.id)
> -> Sort
> Sort Key: id
> -> Append
> -> Seq Scan on ta
Tom Lane wrote:
Nedyalko Borisov writes:
In summary, we are making two suggestions:
1. Extend the optimizer to consider joins between child tables when hierarchies
are joined together.
We already handle this for the case where the join is nestloop with
inner index scan, and I'm not c
Nedyalko Borisov writes:
> In summary, we are making two suggestions:
> 1. Extend the optimizer to consider joins between child tables when
> hierarchies are joined together.
We already handle this for the case where the join is nestloop with
inner index scan, and I'm not convinced that there's
Hi all,
We are working with Aster for the summer and we would like to bounce some ideas
that we are having for some possible PostgreSQL extensions. In order to
describe our ideas we will use the following example:
create table msg(
msg_id int,
msg text );
create table receiver(
msg_id i
16 matches
Mail list logo
