Hi,
I have a partitioned table(partitioned on date) .There are about 1 million
insertions per day. There is a column called mess_id. This column is updated
.But update query is taking huge time.When i checked , this column is not
unique, and most of the time its having null . Say everyday out
Hello Suhas,
You need to supply good information for an accurate answer. Please have a look
at this link:
http://wiki.postgresql.org/wiki/Slow_Query_Questions
Kind regards,
Willem
Date: Wed, 5 Dec 2012 00:10:10 -0800
From: suha...@verse.in
To: pgsql-performance@postgresql.org
[sorry for resuming an old thread]
[cut]
Question is... will that remove the performance penalty of HyperThreading?
So I've added to my todo list to perform a test to verify this claim :)
done.
on this box:
in a brief: the box is dell a PowerEdge r720 with 16GB of RAM,
the cpu is a
On 12/05/2012 10:34 AM, Andrea Suisani wrote:
[sorry for resuming an old thread]
[cut]
Question is... will that remove the performance penalty of
HyperThreading?
So I've added to my todo list to perform a test to verify this claim :)
done.
on this box:
in a brief: the box is dell a
On Wed, Dec 5, 2012 at 1:51 PM, Jean-David Beyer jeandav...@verizon.net wrote:
I thought that postgreSQL did its own journalling, if that is the proper
term, so why not use an ext2 file system to lower overhead?
Because you can still have metadata-level corruption.
--
Sent via
On 12/05/2012 11:51 AM, Jean-David Beyer wrote:
I thought that postgreSQL did its own journalling, if that is the
proper term, so why not use an ext2 file system to lower overhead?
Postgres journalling will not save you from a corrupt file system.
cheers
andrew
--
Sent via
On Tue, Dec 4, 2012 at 3:42 PM, Jeff Janes jeff.ja...@gmail.com wrote:
(Regarding http://explain.depesz.com/s/4MWG, wrote)
But I am curious about how the cost estimate for the primary key look
up is arrived at:
Index Scan using cons_pe_primary_key on position_effect
(cost=0.00..42.96
On Wed, Dec 5, 2012 at 2:39 PM, Jeff Janes jeff.ja...@gmail.com wrote:
I'm not sure that this change would fix your problem, because it might
also change the costs of the alternative plans in a way that
neutralizes things. But I suspect it would fix it. Of course, a
correct estimate of the
Jeff Janes jeff.ja...@gmail.com writes:
I now see where the cost is coming from. In commit 21a39de5809 (first
appearing in 9.2) the fudge factor cost estimate for large indexes
was increased by about 10 fold, which really hits this index hard.
This was fixed in commit bf01e34b556 Tweak
Hey guys,
This isn't a question, but a kind of summary over a ton of investigation
I've been doing since a recent upgrade. Anyone else out there with
big iron might want to confirm this, but it seems pretty reproducible.
This seems to affect the latest 3.2 mainline and by extension, any
platform
Hi,
I'm struggling with a query for some time and the major problem of the
query is that the statistics are way wrong on a particular operation:
- Nested Loop (cost=3177.72..19172.84 rows=*2* width=112) (actual
time=139.221..603.929 rows=*355331* loops=1)
Join Filter: (l.location_id =
Where as I can't say I yet tried out the 3.4 kernel, I can say that I am
running 3.2 too, and maybe there is a connection to the past issues of strange
CPU behavior I have had (as you know and have been so kind to try helping me
solve). I will without a doubt try out 3.4 or 3.6 within the
On Wed, Dec 5, 2012 at 10:28 AM, Shaun Thomas stho...@optionshouse.com wrote:
Hey guys,
This isn't a question, but a kind of summary over a ton of investigation
I've been doing since a recent upgrade. Anyone else out there with
big iron might want to confirm this, but it seems pretty
On 12/05/2012 04:19 PM, Daniel Farina wrote:
Is 3.2 a significant regression from previous releases, or is 3.4 just
faster? Your wording only indicates that older kernel is slow, but
your tone would suggest that you feel this is a regression, cf.
It's definitely a regression. I'm trying to
On Wed, Dec 5, 2012 at 04:25:28PM -0600, Shaun Thomas wrote:
On 12/05/2012 04:19 PM, Daniel Farina wrote:
Is 3.2 a significant regression from previous releases, or is 3.4 just
faster? Your wording only indicates that older kernel is slow, but
your tone would suggest that you feel this is
On 12/05/2012 04:41 PM, Bruce Momjian wrote:
Ah, that is interesting about 2.6. I had wondered how Debian stable
would have performed, 2.6.32-5. This relates to a recent discussion
about the appropriateness of Ubuntu for database servers:
Hmm. I may have to recant. I just removed our
On Wed, Dec 5, 2012 at 4:04 PM, Shaun Thomas stho...@optionshouse.com wrote:
On 12/05/2012 04:41 PM, Bruce Momjian wrote:
Ah, that is interesting about 2.6. I had wondered how Debian stable
would have performed, 2.6.32-5. This relates to a recent discussion
about the appropriateness of
On Thu, Dec 6, 2012 at 1:28 AM, Shaun Thomas stho...@optionshouse.com wrote:
This isn't a question, but a kind of summary over a ton of investigation
I've been doing since a recent upgrade. Anyone else out there with
big iron might want to confirm this, but it seems pretty reproducible.
This
18 matches
Mail list logo
