Hi all.
I'd like to know how efficient is inheritance when the number of
children gets higher and higher.
I mean both with and without the constraint exclusion.
Will this change with 9.0 or possibly 9.1?
Thanks.
--
Vincenzo Romano
NotOrAnd Information Technologies
NON QVIETIS MARIBVS NAVTA PERI
On 1 May 2010, at 12:56, Alban Hertroys wrote:
> You could argue that some logic could be added to the handling of prepared
> statements to insert query-subplans depending on what data you use for your
> parameters, but then you're moving back in the direction of unprepared
> statements (namely
On 1 May 2010, at 5:33, John R Pierce wrote:
> Greg Smith wrote:
> my sql developer, who's been doing oracle for 15+ years, says postgres'
> partitioning is flawed from his perspective because if you have a prepared
> statement like..
>
> SELECT fields FROM partitioned_table WHERE primarykey
2010/5/1 John R Pierce :
> Greg Smith wrote:
>>
>> Enterprise grade doesn't mean anything. Partitioning designs that require
>> thousands of child tables to work right are fundamentally misdesigned
>> anyway, so there is no reason for any of the contributors to the project to
>> work on improving
Greg Smith wrote:
Enterprise grade doesn't mean anything. Partitioning designs that
require thousands of child tables to work right are fundamentally
misdesigned anyway, so there is no reason for any of the contributors
to the project to work on improving support for them. There are far
too
2010/5/1 Greg Smith :
> Vincenzo Romano wrote:
>>
>> While I can agree that "Enterprise grade" is a buzzword, it does mean
>> something: "very large amount of data" among other.
>>
>
> http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
>
> It's quite straighforward to get PostgreSQL
Vincenzo Romano wrote:
While I can agree that "Enterprise grade" is a buzzword, it does mean
something: "very large amount of data" among other.
http://thedailywtf.com/Articles/Bitten_by_the_Enterprise_Bug.aspx
It's quite straighforward to get PostgreSQL up and running with many
terabytes
2010/5/1 Greg Smith :
> Vincenzo Romano wrote:
>>
>> I argued that O(n) stuff will keep it away from "enterprise grade"
>> applications.
>> I've been told earlier that "It is fine for dozens of child tables,
>> but not thousands;
>> it does need improvement."
>> This is not enterprise grade
>
> Ent
Vincenzo Romano wrote:
I argued that O(n) stuff will keep it away from "enterprise grade" applications.
I've been told earlier that "It is fine for dozens of child tables,
but not thousands;
it does need improvement."
This is not enterprise grade
Enterprise grade doesn't mean anything. Partiti
On Fri, Apr 30, 2010 at 00:19, Vincenzo Romano
wrote:
> For example, the Linux kernel made the big jump with server hardware
> thanks also to the O(1) schedulers.
Uhh linux has not had a O(1) scheduler since 2.6.23, its supposedly
O(log n) now. =)
--
Sent via pgsql-general mailing list (pgsql
Alvaro Herrera wrote:
> Vincenzo Romano wrote:
>
> > This is not enterprise grade.
>
> "Enterprise grade" is nothing but a buzzword. Oh, it's also a moving
> target. We've been not enterprise grade for years, always one feature
> behind (and strangely, the one lacking feature is always the one
Vincenzo Romano wrote:
> This is not enterprise grade.
"Enterprise grade" is nothing but a buzzword. Oh, it's also a moving
target. We've been not enterprise grade for years, always one feature
behind (and strangely, the one lacking feature is always the one of
interest to the complainant).
--
2010/4/30 Alvaro Herrera :
> Vincenzo Romano wrote:
>
>> In this specific case, if you think about "inheritance for
>> partitioning" and you stick with the example idea of "one partition
>> per month", then the current solution is more than OK.
>> In the real world, that is not really the general c
Vincenzo Romano wrote:
> In this specific case, if you think about "inheritance for
> partitioning" and you stick with the example idea of "one partition
> per month", then the current solution is more than OK.
> In the real world, that is not really the general case, especially in
> the "enterpri
On Fri, Apr 30, 2010 at 08:44:26AM +0200, Vincenzo Romano wrote:
> >>> Should I move to an "enterprise grade" version of PostgreSQL?
> >>
> >> The enterprise grade version of PostgreSQL is the community
> >> version.
> >>
> >> Proprietary forks exist, but they don't fix this kind of problem.
> >> :
2010/4/30 Vincenzo Romano :
> 2010/4/30 David Fetter :
>> On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
>>> > No info about this point (partial indexes)?
>>> > Is also this geared with linear algorithms ?
>>>
>>> Should I move to an "enterprise grade" version of PostgreSQL?
>>
>>
2010/4/30 David Fetter :
> On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
>> > No info about this point (partial indexes)?
>> > Is also this geared with linear algorithms ?
>>
>> Should I move to an "enterprise grade" version of PostgreSQL?
>
> The enterprise grade version of Post
On Thu, Apr 29, 2010 at 11:29:36AM +0200, Vincenzo Romano wrote:
> > No info about this point (partial indexes)?
> > Is also this geared with linear algorithms ?
>
> Should I move to an "enterprise grade" version of PostgreSQL?
The enterprise grade version of PostgreSQL is the community version.
2010/4/26 Vincenzo Romano :
> 2010/4/26 Bruce Momjian :
>> Vincenzo Romano wrote:
>>> Hi all.
>>>
>>> I'm wondering how efficient the inheritance can be.
>>> I'm using the constraint exclusion feature and for each child table
>>> (maybe but one) I have a proper CHECK constraint.
>>> How efficient c
2010/4/26 Bruce Momjian :
> Vincenzo Romano wrote:
>> Hi all.
>>
>> I'm wondering how efficient the inheritance can be.
>> I'm using the constraint exclusion feature and for each child table
>> (maybe but one) I have a proper CHECK constraint.
>> How efficient can the query planner be in choosing t
Vincenzo Romano wrote:
> Hi all.
>
> I'm wondering how efficient the inheritance can be.
> I'm using the constraint exclusion feature and for each child table
> (maybe but one) I have a proper CHECK constraint.
> How efficient can the query planner be in choosing the right child
> tables in the ca
Hi all.
I'm wondering how efficient the inheritance can be.
I'm using the constraint exclusion feature and for each child table
(maybe but one) I have a proper CHECK constraint.
How efficient can the query planner be in choosing the right child
tables in the case of, say, thousands of them?
Would
22 matches
Mail list logo
