I have logged one day data and found the checkpoint is rather
frequently(detail: https://gist.github.com/3088338). Not sure if it is
normal, but the average time of checkpoint is about 100sec~200sec, it seems
related with my settings:
574 checkpoint_segments = 64
575 wal_keep_segments = 5000
I se
On Tue, Jul 10, 2012 at 5:37 PM, Craig Ringer 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, people who're
> do
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
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
>
On Thu, Jul 5, 2012 at 10:33 PM, Reza Taheri 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 feature. I
> k
On Tuesday, July 10, 2012 03:36:35 PM Jeff Janes wrote:
> On Tue, Jul 10, 2012 at 5:44 AM, Andres Freund
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
On Tue, Jul 10, 2012 at 5:44 AM, Andres Freund 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 flush all dirt
On Tuesday, July 10, 2012 08:14:00 AM Maxim Boguk wrote:
> On Tue, Jul 10, 2012 at 4:03 PM, David Kerr 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 ha
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 c
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
On 10 July 2012 18:36, Pena Kupen wrote:
> 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.
>
> How should I handle this situation and use function?
>
I would star
On Tue, Jul 10, 2012 at 6:36 PM, Pena Kupen wrote:
> 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_
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 >= '2011-1-
13 matches
Mail list logo
