hello ...
yeah, this is fairly complicated.
greg:
can you send me how far you got?
i would be curious to see how you have attacked this issue.
i am still in the process of checking the codes.
we somehow have to find a solution for that. otherwise we are in slight trouble
here.
it seems we have
On Sun, Jul 25, 2010 at 6:40 PM, Greg Stark wrote:
> 2010/7/25 Robert Haas :
>> 2010/7/25 PostgreSQL - Hans-Jürgen Schönig :
>>>
>>> On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote:
>>>
I think the right way to approach this is to teach the planner about
merge sorts.
>
> For w
2010/7/25 Robert Haas :
> 2010/7/25 PostgreSQL - Hans-Jürgen Schönig :
>>
>> On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote:
>>
>>> I think the right way to approach this is to teach the planner about
>>> merge sorts.
For what it's worth I think this is a belt-and-suspenders type of
si
2010/7/25 PostgreSQL - Hans-Jürgen Schönig :
>
> On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote:
>
>> On Fri, Jul 23, 2010 at 10:04:00PM +0200, Hans-Jürgen Schönig wrote:
>>> create table foo ( x date );
>>> create table foo_2010 () INHERITS (foo)
>>> create table foo_200
On Jul 25, 2010, at 11:56 AM, Martijn van Oosterhout wrote:
> On Fri, Jul 23, 2010 at 10:04:00PM +0200, Hans-Jürgen Schönig wrote:
>> create table foo ( x date );
>> create table foo_2010 () INHERITS (foo)
>> create table foo_2009 () INHERITS (foo)
>> create table foo_2008 ()
On Fri, Jul 23, 2010 at 10:04:00PM +0200, Hans-Jürgen Schönig wrote:
> create table foo ( x date );
> create table foo_2010 () INHERITS (foo)
> create table foo_2009 () INHERITS (foo)
> create table foo_2008 () INHERITS (foo)
>
> now we add constraints to make sure that dat
On 7/23/2010 11:04 PM, Hans-Jürgen Schönig wrote:
does anybody see a solution to this problem?
what are the main showstoppers to make something like this work?
I think we should absolutely make this work when we have a good
partitioning implementation.
That said, I don't think it's wise to p
hello everybody,
i have just come across some issue which has been bugging me for a while.
consider:
SELECT * FROM foo ORDER BY bar;
if we have an index on bar, we can nicely optimize away the sort step by
consulting the index - a btree will return sorted output.
under normal circumstan
