On Jul 9, 2012, at 10:51 PM, Maxim Boguk wrote:
But what appears to be happening is that all of the data is being written out
at the end of the checkpoint.
This happens at every checkpoint while the system is under load.
I get the feeling that this isn't the correct behavior and
On Tue, Jul 10, 2012 at 4:03 PM, David Kerr d...@mr-paradox.net wrote:
On Jul 9, 2012, at 10:51 PM, Maxim Boguk wrote:
But what appears to be happening is that all of the data is being written
out at the end of the checkpoint.
This happens at every checkpoint while the system is under
On 7/9/2012 11:14 PM, Maxim Boguk wrote:
On Tue, Jul 10, 2012 at 4:03 PM, David Kerr d...@mr-paradox.net
mailto:d...@mr-paradox.net wrote:
On Jul 9, 2012, at 10:51 PM, Maxim Boguk wrote:
But what appears to be happening is that all of the data is
being written out at
Yes, you're right ! The process checks if all these tables exist before
creating them. So it might be the SELECT that takes time. To check existence, I
use the following query :
select * from pg_tables where tablename='the_table';
May be it's not the best way. And I launch a query per table !
Hi,
I have searched solution to my problem a few days. On my query, there is big
performance problem.
It seems to me, that problem is on where-part of sql and it's function.
My sql is:
select count(*)
from table_h
where
level = get_level_value(11268,id,area) and
(date1 =
Hi and thank's guys!
First trying this Brendan's recommendation.
It seems only a small difference between sql and PL/pgSQL. from 40--37. Not so
good yet.
I will try Maxim's little later and you all know.
--
kupen
Brendan Jurd [dire...@gmail.com] kirjoitti:
On 10 July 2012 18:36, Pena Kupen
Hello again,
Seems to be ok, by adding normal outer join and some fields on where-part.
Previous, I use to used with Oracle and Sybase databases as much as possible
functions/procedures.
There ware something to do with performance: Do it on server, not in client.
Typically all programs were
On Tuesday, July 10, 2012 08:14:00 AM Maxim Boguk wrote:
On Tue, Jul 10, 2012 at 4:03 PM, David Kerr d...@mr-paradox.net wrote:
On Jul 9, 2012, at 10:51 PM, Maxim Boguk wrote:
But what appears to be happening is that all of the data is being
written out at the end of the checkpoint.
On Tue, Jul 10, 2012 at 5:44 AM, Andres Freund and...@2ndquadrant.com wrote:
On Tuesday, July 10, 2012 08:14:00 AM Maxim Boguk wrote:
So kernel doesn't start write any pages out in background before it has at
least 13Gb dirty pages in kernel memory.
And at end of the checkpoint kernel trying
On Tuesday, July 10, 2012 03:36:35 PM Jeff Janes wrote:
On Tue, Jul 10, 2012 at 5:44 AM, Andres Freund and...@2ndquadrant.com
wrote:
On Tuesday, July 10, 2012 08:14:00 AM Maxim Boguk wrote:
So kernel doesn't start write any pages out in background before it has
at least 13Gb dirty pages in
On Thu, Jul 5, 2012 at 10:33 PM, Reza Taheri rtah...@vmware.com wrote:
Just to be clear, we have a number of people from different companies working
on the kit. This is not a VMware project, it is a TPC project. But I hear you
regarding coming in from the cold and asking for a major db engine
Hi Merlin,
We are moving up to a larger testbed, and are planning to use 9.2. But the
results will not comparable to our 8.4 results due to differences in hardware.
But that comparison is a useful one. I'll try for a quick test on the new
hardware with 8.4 before moving to 9.2.
Thanks,
Reza
Hi
After seeing a few discussions here and on Stack Overflow I've put
together a quick explanation of why DELETE FROM table; may be faster
than TRUNCATE table for people doing unit testing on lots of tiny
tables, people who're doing this so often they care how long it takes.
I'd love it if
On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer ring...@ringerc.id.au wrote:
Hi
After seeing a few discussions here and on Stack Overflow I've put together
a quick explanation of why DELETE FROM table; may be faster than TRUNCATE
table for people doing unit testing on lots of tiny tables,
14 matches
Mail list logo
