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
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 conquer
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
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 version
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, and
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
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 in Greenplum
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 working
patch...
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
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 queue.
I
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
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'd
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 selective quote
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.
--
:[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 Why it no uses indexes
: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 it in the
unapplied patches queue
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
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 code
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 child
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
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,
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
=# explain SELECT * FROM n_traf ORDER BY date_time DESC LIMIT 1;
QUERY PLAN
-
Limit (cost=824637.69..824637.69 rows=1 width=32)
-
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;
QUERY
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
26 matches
Mail list logo
