Jignesh, All:
Most of our Solaris users have been, I think, following Jignesh's advice
from his benchmark tests to set ZFS page size to 8K for the data zpool.
However, I've discovered that this is sometimes a serious problem for
some hardware.
For example, having the recordsize set to 8K on a Su
Now that it's time to buy a new computer, Dell has changed their RAID models
from the Perc6 to Perc H200 and such. Does anyone know what's inside these? I
would hope they've stuck with the Megaraid controller...
Also, I can't find any info on Dell's site about how these devices can be
config
El 07/05/2010 16:10, Mark Stosberg escribió:
You can use TRUNCATE instead DELETE. TRUNCATE is more efficient and
faster that DELETE.
Thanks for the suggestion. However, TRUNCATE is not compatible with
Slony, and we also have some rows which remain in table.
Now, we need more info
On 05/05/2010 01:25 PM, Richard Yen wrote:
Problem is, I have foreign keys that link almost all of our tables together (as
a business requirement/IT policy). However, I know (er, I have a gut feeling)
that many people out there have successfully deployed table partitioning, so
I'm hoping to s
"Kevin Grittner" writes:
> Alexander Korotkov wrote:
>>> I just don't find why it is coincidence. I think that such plan
>>> will always produce result ordered by two columns, because such
>>> nested index scan always produce this result.
> Assuming a nested index scan, or any particular plan,
Alexander Korotkov wrote:
> Alexander Korotkov wrote:
>>> Well, no, because that plan wouldn't produce the specified
>>> ordering; or at least it would be a lucky coincidence if it did.
>>> It's only sorting on t1.value.
>>>
>> I just don't find why it is coincidence. I think that such plan
>>
I found my mistake. My supposition is working only if value column in t1
table is unique. But if I replace the index by unique one then plan is the
same.
On Mon, May 3, 2010 at 5:57 PM, Alexander Korotkov wrote:
> Well, no, because that plan wouldn't produce the specified ordering;
>> or at least
>
> Well, no, because that plan wouldn't produce the specified ordering;
> or at least it would be a lucky coincidence if it did. It's only
> sorting on t1.value.
>
I just don't find why it is coincidence. I think that such plan will always
produce result ordered by two columns, because such neste
> You can use TRUNCATE instead DELETE. TRUNCATE is more efficient and
> faster that DELETE.
Thanks for the suggestion. However, TRUNCATE is not compatible with
Slony, and we also have some rows which remain in table.
> Now, we need more information about your system to give you a certain
> so
El 07/05/2010 15:37, Mark Stosberg escribió:
Hello,
We've been a satified user of PostgreSQL for several years, and use it
to power a national pet adoption website: http://www.adoptapet.com/
Recently we've had a regularly-timed middle-of-the-night problem where
database handles are exhausted fo
On Fri, May 07, 2010 at 09:37:42AM -0400, Mark Stosberg wrote:
>
> Hello,
>
> We've been a satified user of PostgreSQL for several years, and use it
> to power a national pet adoption website: http://www.adoptapet.com/
>
> Recently we've had a regularly-timed middle-of-the-night problem where
>
Hello,
We've been a satified user of PostgreSQL for several years, and use it
to power a national pet adoption website: http://www.adoptapet.com/
Recently we've had a regularly-timed middle-of-the-night problem where
database handles are exhausted for a very brief period.
In tracking it down, I
12 matches
Mail list logo
