Tom Lane wrote:
> Alvaro Herrera writes:
>> I think there should be a way to refer to individual partitions as
>> objects.
>
> Yeah, the individual partitions should be nameable tables, otherwise we
> will be reinventing a *whole* lot of management stuff to little gain.
> I don't actually think t
Simon Riggs escribió:
> Hopefully, notions of partitioning won't be directly tied to chunking of
> data for parallel query access. Most queries access recent data and
> hence only a single partition (or stripe), so partitioning and
> parallelism and frequently exactly orthogonal.
I think there
Alvaro Herrera writes:
> I think there should be a way to refer to individual partitions as
> objects.
Yeah, the individual partitions should be nameable tables, otherwise we
will be reinventing a *whole* lot of management stuff to little gain.
I don't actually think there is anything wrong with
On Wed, 2009-05-06 at 17:55 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2009-05-01 at 11:27 -0400, Robert Haas wrote:
> >> The problem has been finding someone who has both the time and the
> >> ability to do the work.
>
> > Unfortunately there has been significant debate over which
Matthew Wakeling writes:
> Here is my patch ported over to the seg contrib package, attached. Apply
> it to seg.c and all should be well. A similar thing needs to be done to
> cube, but I haven't looked at that.
Teodor, Oleg, do you intend to review/apply this patch?
re
Simon Riggs writes:
> On Fri, 2009-05-01 at 11:27 -0400, Robert Haas wrote:
>> The problem has been finding someone who has both the time and the
>> ability to do the work.
> Unfortunately there has been significant debate over which parts of
> partitioning need to be improved. My own view is tha
On Wed, 2009-05-06 at 10:31 +0200, Dimitri wrote:
> I've already tried a target 1000 and the only thing it changes
> comparing to the current 100 (default) is instead of 2404 rows it says
> 240 rows, but the plan remaining the same..
Try both of these things
* REINDEX on the index being used in
On Fri, 2009-05-01 at 11:27 -0400, Robert Haas wrote:
> The problem has been finding someone who has both the time and the
> ability to do the work.
Unfortunately there has been significant debate over which parts of
partitioning need to be improved. My own view is that considerable
attention ne
On Wed, May 06, 2009 at 04:48:21PM +0200, Dimitri wrote:
> Hi Ken,
>
> yes, I may do it, but I did not expect to come into profiling initially :-)
> I expected there is just something trivial within a plan that I just
> don't know.. :-)
>
> BTW, is there already an integrated profiled within a co
Hi Ken,
yes, I may do it, but I did not expect to come into profiling initially :-)
I expected there is just something trivial within a plan that I just
don't know.. :-)
BTW, is there already an integrated profiled within a code? or do I
need external tools?..
Rgds,
-Dimitri
On 5/6/09, Kenneth
On Wed, May 06, 2009 at 09:38:59AM +0200, Dimitri wrote:
> Hi,
>
> any idea if there is a more optimal execution plan possible for this query:
>
> select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as hbeg,
> H.END_DATE as hend, H.NOTE as hnote
> from HISTORY H
I supposed in case with prepare and then execute a query optimizer is
no more coming in play on "execute" phase, or did I miss something?..
Forget to say: query cache is disabled on MySQL side.
Rgds,
-Dimitri
On 5/6/09, Craig Ringer wrote:
> Dimitri wrote:
>> Hi Chris,
>>
>> the only problem I
On Wed, May 06, 2009 at 10:04:33PM +0800, Craig Ringer wrote:
Can the genetic query optimizer come into play on small queries?
On Wed, 6 May 2009, Kenneth Marshall wrote:
No.
Yes. But you would have had to have set some really weird configuration.
Matthew
--
And the lexer will say "Oh look
No.
Ken
On Wed, May 06, 2009 at 10:04:33PM +0800, Craig Ringer wrote:
> Dimitri wrote:
> > Hi Chris,
> >
> > the only problem I see here is it's 2 times slower vs InnoDB, so
> > before I'll say myself it's ok I want to be sure there is nothing else
> > to do.. :-)
>
> Can the genetic query optim
Dimitri wrote:
> Hi Chris,
>
> the only problem I see here is it's 2 times slower vs InnoDB, so
> before I'll say myself it's ok I want to be sure there is nothing else
> to do.. :-)
Can the genetic query optimizer come into play on small queries?
--
Craig Ringer
--
Sent via pgsql-performance
Folks, first of all:
- I used a fixed reference value just to simplify the case analyzing
and isolate it as max as possible, of course during my tests all
values are random :-)
- final goal of the test is to analyze scalability, so yes, concurrent
sessions with random keys are growing from 1 to
On May 6, 2009, at 7:53 AM, Richard Huxton wrote:
Dimitri wrote:
I'll try to answer all mails at once :-))
- query is running fully in RAM, no I/O, no network, only CPU time
- looping 100 times the same query gives 132ms total time (~1.32ms
per
query), while it's 44ms on InnoDB (~0.44ms per
On Wed, May 06, 2009 at 02:49:23PM +0200, Dimitri wrote:
> The story is simple: for the launching of MySQL 5.4 I've done a
> testing comparing available on that time variations of InnoDB engines,
> and at the end by curiosity started the same test with PostgreSQL
> 8.3.7 to see if MySQL performance
On Wed, May 06, 2009 at 04:01:03PM +0800, Craig Ringer wrote:
> Dimitri wrote:
>> Hi,
>> any idea if there is a more optimal execution plan possible for this
>> query:
>> select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as
>> hbeg,
>> H.END_DATE as hend, H.NOTE as hno
Dimitri wrote:
I'll try to answer all mails at once :-))
- query is running fully in RAM, no I/O, no network, only CPU time
- looping 100 times the same query gives 132ms total time (~1.32ms per
query), while it's 44ms on InnoDB (~0.44ms per query)
Well, assuming you're happy that PG is tuned
The story is simple: for the launching of MySQL 5.4 I've done a
testing comparing available on that time variations of InnoDB engines,
and at the end by curiosity started the same test with PostgreSQL
8.3.7 to see if MySQL performance level is more close to PostgreSQL
now (PG was a strong true winn
I'll try to answer all mails at once :-))
- query is running fully in RAM, no I/O, no network, only CPU time
- looping 100 times the same query gives 132ms total time (~1.32ms per
query), while it's 44ms on InnoDB (~0.44ms per query)
- disabling seq scan forcing a planner to use an index scan, a
Dimitri wrote:
> I've run several tests before and now going in depth to understand if
> there is nothing wrong. Due such a single query time difference InnoDB
> is doing 2-3 times better TPS level comparing to PostgreSQL..
Why don't you use MySQL then?
Or tune PostgreSQL?
Yours,
Laurenz Albe
--
On Wed, May 6, 2009 at 7:46 AM, Merlin Moncure wrote:
> prepare history_stat(char(10) as
typo:
prepare history_stat(char(10)) as
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performan
On Wed, May 6, 2009 at 3:38 AM, Dimitri wrote:
> Hi,
>
> any idea if there is a more optimal execution plan possible for this query:
>
> select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as hbeg,
> H.END_DATE as hend, H.NOTE as hnote
> from HISTORY H, STAT S
>
On Wed, 6 May 2009, Heikki Linnakangas wrote:
Total runtime: 1.442 ms
It's pretty clear that this query isn't even going to disc - it's all CPU
time. That can be the case if you run the exact same query more than once,
and it can cause your EXPLAIN output to be vastly different from your rea
Dimitri wrote:
Hi Richard,
no, of course it's not based on explain :-)
I've run several tests before and now going in depth to understand if
there is nothing wrong. Due such a single query time difference InnoDB
is doing 2-3 times better TPS level comparing to PostgreSQL..
And you are satisfie
Dimitri wrote:
Hi Chris,
the only problem I see here is it's 2 times slower vs InnoDB
How do you know? This isn't just based on the explain values reported,
is it?
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make chang
Hi Richard,
no, of course it's not based on explain :-)
I've run several tests before and now going in depth to understand if
there is nothing wrong. Due such a single query time difference InnoDB
is doing 2-3 times better TPS level comparing to PostgreSQL..
Rgds,
-Dimitri
On 5/6/09, Richard Hu
Hi Chris,
the only problem I see here is it's 2 times slower vs InnoDB, so
before I'll say myself it's ok I want to be sure there is nothing else
to do.. :-)
Rgds,
-Dimitri
On 5/6/09, Chris wrote:
> Dimitri wrote:
>> Hi Craig,
>>
>> yes, you detailed very well the problem! :-)
>> all those CHA
Hi Heikki,
I've already tried a target 1000 and the only thing it changes
comparing to the current 100 (default) is instead of 2404 rows it says
240 rows, but the plan remaining the same..
Rgds,
-Dimitri
On 5/6/09, Heikki Linnakangas wrote:
> Dimitri wrote:
>> any idea if there is a more optima
Dimitri wrote:
Hi Craig,
yes, you detailed very well the problem! :-)
all those CHAR columns are so just due historical issues :-) as well
they may contains anything else and not only numbers, that's why..
Also, all data inside are fixed, so VARCHAR will not save place, or
what kind of performan
Dimitri wrote:
any idea if there is a more optimal execution plan possible for this query:
select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as hbeg,
H.END_DATE as hend, H.NOTE as hnote
from HISTORY H, STAT S
where S.REF = H.REF_STAT
and H.R
Hi Craig,
yes, you detailed very well the problem! :-)
all those CHAR columns are so just due historical issues :-) as well
they may contains anything else and not only numbers, that's why..
Also, all data inside are fixed, so VARCHAR will not save place, or
what kind of performance issue may we e
Dimitri wrote:
Hi,
any idea if there is a more optimal execution plan possible for this query:
select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as hbeg,
H.END_DATE as hend, H.NOTE as hnote
from HISTORY H, STAT S
where S.REF = H.REF_STAT
an
Hi,
any idea if there is a more optimal execution plan possible for this query:
select S.REF as stref, S.NAME as stnm, H.HORDER as hord, H.BEGIN_DATE as hbeg,
H.END_DATE as hend, H.NOTE as hnote
from HISTORY H, STAT S
where S.REF = H.REF_STAT
and H.REF_OBJECT =
36 matches
Mail list logo
