Le mardi 01 mars 2011 07:20:19, Tom Lane a écrit :
> Marc Cousin writes:
> > The Monday 28 February 2011 16:35:37, Tom Lane wrote :
> >> Could we see a concrete example demonstrating that? I agree with Heikki
> >> that it's not obvious what you are testing that would have such
> >> behavior. I ca
Marc Cousin writes:
> The Monday 28 February 2011 16:35:37, Tom Lane wrote :
>> Could we see a concrete example demonstrating that? I agree with Heikki
>> that it's not obvious what you are testing that would have such behavior.
>> I can think of places that would have O(N^2) behavior in the leng
Ok, let us look into Tsung. On the other hand, (this might be a bit out of
context) we want to load/stress test the Windows client application at that
accessed the PostgreSQL through an App Server. This is to gauge if the App
Server can take the load to handle the client request. Is there a tool th
Craig James writes:
> Then I thought maybe putting a foreign-key constraint on table "my_version"
> would solve the problem:
>alter table my_version add constraint fk_my_view foreign key(version_id)
>references registry.version(version_id) on delete cascade;
> That way, the planner woul
Craig James writes:
Here is the "bad" query, which is run on the view:
em=> explain analyze
select version.version_id, version.isosmiles
from hitlist_rows_reset_140
left join version on (hitlist_rows_reset_140.objectid = version.version_id)
where hitlist_rows_reset_140.sortorder >= 1
and hitlis
Hey,
Does anyone have the hardware to test FlashCache with PostgreSQL?
http://perspectives.mvdirona.com/2010/04/29/FacebookFlashcache.aspx
I'd be interested to hear how it performs ...
--
-- Josh Berkus
PostgreSQL Experts I
2011/2/27 Віталій Тимчишин :
>
>
> 27 лютого 2011 р. 19:59 Robert Haas написав:
>>
>> 2011/2/4 Віталій Тимчишин :
>> > Hi, all.
>> > All this optimizer vs hint thread reminded me about crazy idea that got
>> > to
>> > my head some time ago.
>> > I currently has two problems with postgresql optimiz
On Sun, Feb 27, 2011 at 1:39 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 8, 2011 at 5:04 PM, Josh Berkus wrote:
>>> I'm not saying that PostgreSQL couldn't do better on this kind of case,
>>> but that doing better is a major project, not a minor one.
>
>> Specifically, the problem i
Craig James writes:
> My guess (and it's just a wild guess) is that the "left join" is
> forcing a sequence scan or something.
No, that's forcing the other join to be done in toto because it can't
reorder the left join and regular join.
regards, tom lane
--
Sent via pgs
The Monday 28 February 2011 16:35:37, Tom Lane wrote :
> Marc Cousin writes:
> > The Monday 28 February 2011 13:57:45, Heikki Linnakangas wrote :
> >> Testing here with a table with 1000 columns and 100 partitions, about
> >> 80% of the planning time is looking up the statistics on attribute
> >>
On 2/28/11 8:25 AM, Selva manickaraja wrote:
> Hi,
>
> I came across some tools such as Tsung and Bristlecone. Are these fine
> or are there any better tools well suited for this DB?
Tsung is great. I've never used Bristlecone.
--
-- Josh Berkus
We have a medium-sized catalog (about 5 million rows), but some of our customers only
want to see portions of it. I've been experimenting with a customer-specific schema that
contains nothing but a "join table" -- just the primary keys of that portion of
the data that each customer wants to se
croolyc wrote:
> Hi!
> can you help me with performance optimization
> on my machine I have 8 databases with ca. 1-2GB
Performace optimization depends on the workload...
Is that a dedicated server, only for PostgreSQL? I assume it.
> memory: 8GB (4*2GB ecc ram)
Okay, as a first try, set share
Hi!
can you help me with performance optimization
on my machine I have 8 databases with ca. 1-2GB
processor is:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E3110 @ 3.00GHz
stepping : 10
cpu MHz
Hi,
I came across some tools such as Tsung and Bristlecone. Are these fine or
are there any better tools well suited for this DB?
Thank you.
Warmest Regards,
Selvam
Marc Cousin writes:
> The Monday 28 February 2011 13:57:45, Heikki Linnakangas wrote :
>> Testing here with a table with 1000 columns and 100 partitions, about
>> 80% of the planning time is looking up the statistics on attribute
>> width, to calculate average tuple width. I don't see O(n^2) behav
croolyc wrote:
> can you help me with performance optimization
For overall tuning you could start here:
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
If, after some general tuning, you are having problems with slow
queries, it is best if you pick one and show it with EXPLAI
The Monday 28 February 2011 13:57:45, Heikki Linnakangas wrote :
> On 28.02.2011 11:38, Marc Cousin wrote:
> > I've been facing a very large (more than 15 seconds) planning time in a
> > partitioned configuration. The amount of partitions wasn't completely
> > crazy, around 500, not in the thousand
On 28.02.2011 11:38, Marc Cousin wrote:
I've been facing a very large (more than 15 seconds) planning time in a
partitioned configuration. The amount of partitions wasn't completely crazy,
around 500, not in the thousands. The problem was that there were nearly 1000
columns in the parent table (v
On 28.02.2011 11:10, Selva manickaraja wrote:
OK, somehow I got these modules installed. Finally I successfully built and
installed PostgreSQL! I must thank you guys so much for helping.
Now coming to the real issue of the matter. According to the documentation
the "gmake installcheck" can be ru
Hi!
can you help me with performance optimization
on my machine I have 8 databases with ca. 1-2GB
processor is:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E3110 @ 3.00GHz
stepping: 10
cpu MHz
OK, somehow I got these modules installed. Finally I successfully built and
installed PostgreSQL! I must thank you guys so much for helping.
Now coming to the real issue of the matter. According to the documentation
the "gmake installcheck" can be run in various directories. However it seem
to be
22 matches
Mail list logo
