Skip site navigation (1) Skip section navigation (2)

Re: Path question

From: PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Boszormenyi Zoltan <zb(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Path question
Date: 2010-09-01 15:26:15
Message-ID: 620D5B0A-EEFD-412E-B5C2-111568548405@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackers
hello tom,

yeah, we have followed quite a lot of discussion as well ...
and yes, no patches.

as far as this problem is concerned: we are working on a patch and did some prototyping inside the planner already (attached).
the code we have is pretty limited atm (such as checking for a sort clause explicitly and so on - it has no support for windowing related optimizations and so on so far).

the cost model is not our problem - it is a lot easier to read than the code we are fighting with (it is a different level of complexity). i think costs can be handled.

yes, this merging adds some costs for sure. we might see a hell amount of operators being called - but i think given a reasonable number of partitions it is still a lot cheaper than actually resorting ... and, it is a lot more space efficient.
in my practical case i cannot resort because we would simply run out of space. an index scan is expensive but needs no additional sort space ...
and, merge is O(n) which sort is clearly not.

advise is highly appreciated.

	many thanks,

		hans



Attachment: push-down-sort-into-inh-2.patch
Description: application/octet-stream (7.3 KB)

In response to

pgsql-hackers by date

Next:From: David ChristensenDate: 2010-09-01 15:34:29
Subject: permissions bug in RI checks?
Previous:From: David E. WheelerDate: 2010-09-01 15:16:41
Subject: Re: array_agg() NULL Handling

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group