On Mon, Oct 19, 2009 at 6:58 AM, Joe Uhl wrote:
> I have a similar, recent thread titled Partitioned Tables and ORDER BY with
> a decent break down. I think I am hitting the same issue Michal is.
>
> Essentially doing a SELECT against the parent with appropriate constraint
> columns in the WHERE
On Mon, 2009-10-19 at 21:32 +0200, ph...@apra.asso.fr wrote:
> Hi all,
>
> The current discussion about "Indexes on low cardinality columns" let
> me discover this
> "grouped index tuples" patch (http://community.enterprisedb.com/git/)
> and its associated
> "maintain cluster order" patch
> (htt
Hi all,
The current discussion about "Indexes on low cardinality columns" let me
discover this
"grouped index tuples" patch (http://community.enterprisedb.com/git/) and its
associated
"maintain cluster order" patch
(http://community.enterprisedb.com/git/maintain_cluster_order_v5.patch)
This
2009/10/19 Grzegorz Jaśkiewicz :
>
>
> 2009/10/19 Robert Haas
>>
>> 2009/10/19 Grzegorz Jaśkiewicz :
>> >
>> >
>> > On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski
>> > wrote:
>> >>
>> >> We have similar problem and now we are try to find solution. When you
>> >> execute query on partion there
Simon Riggs writes:
> On Mon, 2009-10-19 at 13:58 -0400, Tom Lane wrote:
>> Most read-only functions are stable or even immutable.
> Huh? I mean a function that only contains SELECTs. (How would those ever
> be Stable or Immutable??)
Uh, a function containing SELECTs is exactly the use-case for
On Mon, 2009-10-19 at 13:58 -0400, Tom Lane wrote:
>
> Most read-only functions are stable or even immutable.
Huh? I mean a function that only contains SELECTs. (How would those ever
be Stable or Immutable??)
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-performance mailing
Gerhard Wiesinger writes:
> Is the patch only for 8.5 or even backported to 8.4 and 8.3?
That patch will *not* be backported. It hasn't even got through beta yet.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make ch
Simon Riggs writes:
> On Mon, 2009-10-19 at 13:43 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> I think we should have a 4th class of functions,
>>> volatile-without-side-effects (better name needed, obviously).
>>
>> What for? There wouldn't be that many, I think. random() and
>> clock_ti
On Sun, 18 Oct 2009, Tom Lane wrote:
Robert Haas writes:
On Sun, Oct 18, 2009 at 1:59 PM, Jeff Janes wrote:
Even if country.id is a primary or unique key?
Well, we currently don't have any logic for making inferences based on
unique constraints.
Huh?
http://archives.postgresql.org/pgsql
On Mon, 2009-10-19 at 13:43 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Sat, 2009-10-17 at 21:41 -0400, Tom Lane wrote:
> >> one thing we'd have to consider
> >> is whether it is okay to suppress calculation of columns containing
> >> volatile functions.
>
> > I think we should have a 4th
Simon Riggs wrote:
> I think we should have a 4th class of functions,
> volatile-without-side-effects
Sounds reasonable to me.
> (better name needed, obviously).
Well, from this list (which is where volatile points), mutable seems
closest to OK, but I'm not sure I like any of them.
http
Joe Uhl wrote:
This seems like a pretty major weakness in PostgreSQL partitioning. I
have essentially settled on not being able to do queries against the
parent table when I want to order the results. Going to have to use a
Hibernate interceptor or something similar to rewrite the statements
Simon Riggs writes:
> On Sat, 2009-10-17 at 21:41 -0400, Tom Lane wrote:
>> one thing we'd have to consider
>> is whether it is okay to suppress calculation of columns containing
>> volatile functions.
> I think we should have a 4th class of functions,
> volatile-without-side-effects (better name
On Sat, 2009-10-17 at 21:41 -0400, Tom Lane wrote:
> one thing we'd have to consider
> is whether it is okay to suppress calculation of columns containing
> volatile functions.
I think we should have a 4th class of functions,
volatile-without-side-effects (better name needed, obviously).
That wo
2009/10/19 Robert Haas
> 2009/10/19 Grzegorz Jaśkiewicz :
> >
> >
> > On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski
> > wrote:
> >>
> >> We have similar problem and now we are try to find solution. When you
> >> execute query on partion there is no sorting - DB use index to
> >> retrieve dat
2009/10/19 Grzegorz Jaśkiewicz :
>
>
> On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski
> wrote:
>>
>> We have similar problem and now we are try to find solution. When you
>> execute query on partion there is no sorting - DB use index to
>> retrieve data and if you need let say 50 rows it reads
I wrote:
> Just for fun, I hacked together a first cut at this.
Oh, just for the archives: I forgot about not suppressing volatile
expressions --- checking that would increase the cost of this
significantly, though it's only another line or two.
regards, tom lane
--
Sent
If the table can be clustered on that column, I suspect
it'd be a nice case for the grouped index tuples patch
http://community.enterprisedb.com/git/
Actually, simply clustering on that column might give
major speedups anyway.
Vikul Khosla wrote:
> Folks,
>
> We have just migrated from Oracle to
On Mon, Oct 19, 2009 at 2:43 PM, Vikul Khosla wrote:
> Jeff, Robert, I am still working on the "low cardinality" info you
> requested. Please bear with me.
>
> In the meantime, have the following question:
>
> Are there known "scenarios" where certain types of SQL queries perform
> worse in PG
>
Jeff, Robert, I am still working on the "low cardinality" info you requested.
Please bear with me.
In the meantime, have the following question:
Are there known "scenarios" where certain types of SQL queries perform worse in
PG
than they do in ORacle ?
For example, I have observed some discuss
On Mon, Oct 12, 2009 at 10:14 AM, Michal Szymanski wrote:
We have performance problem with query on partitioned table when query
use order by and we want to use first/last rows from result set.
More detail description:
We have big table where each row is one telephone call (CDR).
Definitni
On Sun, 18 Oct 2009, Scott Marlowe wrote:
You can only write data then commit it so fast to one drive, and that
speed is usually somewhere in the megabyte per second range. 450+150
in 5 minutes is 120 Megs per second, that's pretty fast, but is likely
the max speed of a modern super fast 15k rpm
On Sun, Oct 11, 2009 at 3:30 PM, Michal Szymanski wrote:
> We have similar problem and now we are try to find solution. When you
> execute query on partion there is no sorting - DB use index to
> retrieve data and if you need let say 50 rows it reads 50 rows using
> index. But when you execute on
23 matches
Mail list logo
