Heikki Linnakangas wrote:
> Bruce, would you please add this to the 8.4 patch queue so we remember
> to look at this later?
OK, added to queue, but Tom's patch queue comment is:
This is useless since it does not represent a complete patch; the
provided code calls a lot of Greenplum-private routin
Luke Lonergan wrote:
On 11/7/07 10:21 PM, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
part=# explain SELECT * FROM n_traf ORDER BY date_time LIMIT 1;
QUERY PLAN
--
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
> Here is a (somewhat hurried) self-contained version of the patch under
> discussion. It applies to 8.2.5 and the resultant code compiles and runs. I've
> left in some unneeded parallel stuff (PathLocus struct), which I can weed out
> in a subsequent ve
On 11/7/07 10:21 PM, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
>> part=# explain SELECT * FROM n_traf ORDER BY date_time LIMIT 1;
>> QUERY PLAN
>> -
>> ---
Gregory Stark wrote:
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
I spent today looking at getting this patch into a self contained state.
Working against HEAD I'm getting bogged down in the PathKeyItem to
PathKey/EquivalenceClass/EquivalenceMember(s) change. So I figured I'd divide
and conqu
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
> I spent today looking at getting this patch into a self contained state.
> Working against HEAD I'm getting bogged down in the PathKeyItem to
> PathKey/EquivalenceClass/EquivalenceMember(s) change. So I figured I'd divide
> and conquer to some extent,
Gregory Stark wrote:
cdbpathlocus_pull_above_projection
In particular this is the function I was hoping to see. Anyways as Tom pointed
out previously there's precedent in Postgres as well for subqueries so I'm
sure I'll be able to do it.
(But I'm still not entirely convinced putting the app
BTW - Mark has volunteered to work a Postgres patch together. Thanks Mark!
- Luke
On 10/29/07 10:46 PM, "Mark Kirkwood" <[EMAIL PROTECTED]> wrote:
> Luke Lonergan wrote:
>> Sure - it's here:
>> http://momjian.us/mhonarc/patches_hold/msg00381.html
>>
>>
>
> To clarify - we've fixed this
"Mark Kirkwood" <[EMAIL PROTECTED]> writes:
> Luke Lonergan wrote:
>> Sure - it's here:
>> http://momjian.us/mhonarc/patches_hold/msg00381.html
>
> To clarify - we've fixed this in Greenplum db - the patch as submitted is
> (hopefully) a hint about how to fix it in Postgres, rather than a workin
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> Sure - it's here:
> http://momjian.us/mhonarc/patches_hold/msg00381.html
Luke, this is not a patch, and I'm getting pretty dang tired of seeing
you refer to it as one. What this is is a very-selective extract from
Greenplum proprietary code. If you
Luke Lonergan wrote:
Sure - it's here:
http://momjian.us/mhonarc/patches_hold/msg00381.html
To clarify - we've fixed this in Greenplum db - the patch as submitted
is (hopefully) a hint about how to fix it in Postgres, rather than a
working patch... as its full of non-postgres functions
Sure - it's here:
http://momjian.us/mhonarc/patches_hold/msg00381.html
- Luke
On 10/29/07 6:40 AM, "Gregory Stark" <[EMAIL PROTECTED]> wrote:
> "Luke Lonergan" <[EMAIL PROTECTED]> writes:
>
>> And I repeat - 'we fixed that and submitted a patch' - you can find it in the
>> unapplied patches
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> And I repeat - 'we fixed that and submitted a patch' - you can find it in the
> unapplied patches queue.
I can't find this. Can you point me towards it?
Thanks
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask about Ente
"Luke Lonergan" <[EMAIL PROTECTED]> writes:
> The approach we took was to recognize the ordering of child nodes and
> propagate that to the append in the special case of only one child (after
> CE). This is the most common use-case in 'partitioning', and so is an easy,
> high payoff low amount of
On Sat, 2007-10-27 at 15:12 -0400, Luke Lonergan wrote:
> And I repeat - 'we fixed that and submitted a patch' - you can find it
> in the unapplied patches queue.
I got the impression it was a suggestion rather than a tested patch,
forgive me if that was wrong.
Did the patch work? Do you have tim
rday, October 27, 2007 03:14 PM Eastern Standard Time
To: Heikki Linnakangas; Anton
Cc: pgsql-performance@postgresql.org
Subject:Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC
LIMIT 1
And I repeat - 'we fixed that and submitted a patch' - you can find
Linnakangas [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 27, 2007 05:20 AM Eastern Standard Time
To: Anton
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] partitioned table and ORDER BY indexed_field DESC
LIMIT 1
Anton wrote:
> I repost here my original question
Anton wrote:
> I repost here my original question "Why it no uses indexes?" (on
> partitioned table and ORDER BY indexed_field DESC LIMIT 1), if you
> mean that you miss this discussion.
As I said back then:
The planner isn't smart enough to push the "ORDER BY ... LIMIT ..."
below the append node
2007/10/27, Tom Lane <[EMAIL PROTECTED]>:
> Anton <[EMAIL PROTECTED]> writes:
> > I want ask about problem with partioned tables (it was discussed some
> > time ago, see below). Is it fixed somehow in 8.2.5 ?
>
> No. The patch you mention never was considered at all, since it
> consisted of a sele
Anton <[EMAIL PROTECTED]> writes:
> I want ask about problem with partioned tables (it was discussed some
> time ago, see below). Is it fixed somehow in 8.2.5 ?
No. The patch you mention never was considered at all, since it
consisted of a selective quote from Greenplum source code. It would
not
I want ask about problem with partioned tables (it was discussed some
time ago, see below). Is it fixed somehow in 8.2.5 ?
2007/8/24, Luke Lonergan <[EMAIL PROTECTED]>:
> Below is a patch against 8.2.4 (more or less), Heikki can you take a look at
> it?
>
> This enables the use of index scan of a
Bruce, would you please add this to the 8.4 patch queue so we remember
to look at this later?
It didn't occur to me that we can do that in the degenerate case when
there's just a single node below the Append. A more general solution
would be to check if the pathkeys of all the child nodes match, a
Pn, 2007 08 24 14:53 +0600, Anton rašė:
> Hi.
>
> I just created partitioned table, n_traf, sliced by month
> (n_traf_y2007m01, n_traf_y2007m02... and so on, see below). They are
> indexed by 'date_time' column.
> Then I populate it (last value have date 2007-08-...) and do VACUUM
> ANALYZE ON n_t
Below is a patch against 8.2.4 (more or less), Heikki can you take a look at
it?
This enables the use of index scan of a child table by recognizing sort
order of the append node. Kurt Harriman did the work.
- Luke
Index: cdb-pg/src/backend/optimizer/path/indxpath.c
=
We just fixed this - I'll post a patch, but I don't have time to verify
against HEAD.
- Luke
On 8/24/07 3:38 AM, "Heikki Linnakangas" <[EMAIL PROTECTED]> wrote:
> Anton wrote:
=# explain SELECT * FROM n_traf ORDER BY date_time DESC LIMIT 1;
Anton wrote:
>>> =# explain SELECT * FROM n_traf ORDER BY date_time DESC LIMIT 1;
>>>QUERY PLAN
>> -
>>> Limit (cost=824637.69..824637.69 rows=1 w
> > =# explain SELECT * FROM n_traf ORDER BY date_time DESC LIMIT 1;
> >QUERY PLAN
> -
> > Limit (cost=824637.69..824637.69 rows=1 width=32)
> >
On 8/24/07, Anton <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> I just created partitioned table, n_traf, sliced by month
> (n_traf_y2007m01, n_traf_y2007m02... and so on, see below). They are
> indexed by 'date_time' column.
> Then I populate it (last value have date 2007-08-...) and do VACUUM
> ANALYZE
Hi.
I just created partitioned table, n_traf, sliced by month
(n_traf_y2007m01, n_traf_y2007m02... and so on, see below). They are
indexed by 'date_time' column.
Then I populate it (last value have date 2007-08-...) and do VACUUM
ANALYZE ON n_traf_y2007... all of it.
Now I try to select latest va
29 matches
Mail list logo
