On Mon, May 2, 2011 at 3:58 AM, Claudio Freire wrote:
> Hash joins are very inefficient if they require big temporary files.
Hmm, that's not been my experience. What have you seen?
I've seen a 64-batch hash join beat out a
nested-loop-with-inner-indexscan, which I never woulda believed,
but...
On Fri, May 13, 2011 at 4:13 PM, Josh Berkus wrote:
> Instead, we should be fixing the formulas these are based on and leaving
> RPC alone.
>
> For any data page, there are actually four costs associated with each
> tuple lookup, per:
All true. I suspect that in practice the different between ra
Hi all:
I am adding pgiosim to our testing for new database hardware and I am
seeing something I don't quite get and I think it's because I am using
pgiosim incorrectly.
Specs:
OS: centos 5.5 kernel: 2.6.18-194.32.1.el5
memory: 96GB
cpu: 2x Intel(R) Xeon(R) X5690 @ 3.47GHz (6 core, ht ena
2011/5/13 Josh Berkus :
>
>> I guess maybe the reason why it didn't matter for the OP is that - if
>> the size of the index page in pages is smaller than the pro-rated
>> fraction of effective_cache_size allowed to the index - then the exact
>> value doesn't affect the answer.
>>
>> I apparently ne
> I guess maybe the reason why it didn't matter for the OP is that - if
> the size of the index page in pages is smaller than the pro-rated
> fraction of effective_cache_size allowed to the index - then the exact
> value doesn't affect the answer.
>
> I apparently need to study this code more.
F
On Fri, May 13, 2011 at 3:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 26, 2011 at 9:04 PM, Merlin Moncure wrote:
>>> The very first thing to check is effective_cache_size and to set it to
>>> a reasonable value.
>
>> Actually, effective_cache_size has no impact on costing except
Robert Haas writes:
> On Tue, Apr 26, 2011 at 9:04 PM, Merlin Moncure wrote:
>> The very first thing to check is effective_cache_size and to set it to
>> a reasonable value.
> Actually, effective_cache_size has no impact on costing except when
> planning a nested loop with inner index scan. So,
On Wed, May 4, 2011 at 6:31 AM, Willy-Bas Loos wrote:
> I'm asking them for (real) benchmarks, thanks for the advice. (fio is not
> available for us now to do it myself, grmbl)
> It just occurred to me that it is not necessarily the case that reading the
> indexes causes a lot of random I/O (on th
Robert Haas wrote:
> We've talked in the past (and I still think it's a good idea, but
> haven't gotten around to doing anything about it) about adjusting
> the planner to attribute to each relation the percentage of its
> pages which we believe we'll find in cache. Although many
> complicated
On Tue, Apr 26, 2011 at 9:04 PM, Merlin Moncure wrote:
> On Tue, Apr 26, 2011 at 4:37 PM, Kevin Grittner
> wrote:
>> Sok Ann Yap wrote:
>>
>>> So, index scan wins by a very small margin over sequential scan
>>> after the tuning. I am a bit puzzled because index scan is more
>>> than 3000 times f
> Does someone can help me?
You may want to try pgsql-general instead of this list.
---
Maciek Sakrejda | System Architect | Truviso
1065 E. Hillsdale Blvd., Suite 215
Foster City, CA 94404
(650) 242-3500 Main
www.truviso.com
--
Sent via pgsql-performance mailing list (pgsql-performance@postgre
Hi:
I installed PostgreSQL9.0 from EnterpriseDB with“one click installer” in
windows 7 & 32bit.
and use microsoft visual studio 2010 c++.
I added the libpq.lib to the link property of the project, also included the
lib folder and path.
Successfully compiled .c and .cpp file after transfer .pg
Hi Denis and Cédric
Thanks for your answers.
> Fredrick, What indexes Oracle did choose ? (index-only scan ?)
Oracle chooses a plan which looks like this:
SELECT STATEMENT Optimizer=ALL_ROWS (Cost=5 Card=7 Bytes=182)
VIEW OF 'CONNECTIONS_V' (VIEW) (Cost=5 Card=7 Bytes=182)
UNION-ALL
2011/5/13 Denis de Bernardy :
> I might have misread, but:
>
>> select * from connections where locked_by <> 4711
>> union all
>> select * from connections_locked where locked_by = 4711;
>
>
> The first part will result in a seq scan irrespective of indexes, and the
> second has no index on locked
I might have misread, but:
> select * from connections where locked_by <> 4711
> union all
> select * from connections_locked where locked_by = 4711;
The first part will result in a seq scan irrespective of indexes, and the
second has no index on locked_by. The best you can do is to eliminate t
Hi everyone
We have recently started to port an application from Oracle to PostgreSQL.
So far, we are amazed with how great most things work.
However, we have run into performance problems in one type of query which
is quite common in our application. We have created a (simplified)
reproducible t
On Fri, May 13, 2011 at 1:28 AM, Andres Freund wrote:
> Hi,
>
> On Friday, May 13, 2011 01:10:19 AM Samuel Gendler wrote:
>
> I would suggest doing ALTER FUNCTION blub(blarg) SET work_mem = '512MB';
>
>
Ah! That's perfect and very convenient. Thanks.
--sam
> It's not synchronous at all. The clients create a temporary file for
> the statistics collector and move on. The actual statistics don't get
> updated until the statistics collector decides enough time has passed to
> bother, which defaults to at most every 500ms.
Really? I thought the clients
Hi,
On Friday, May 13, 2011 01:10:19 AM Samuel Gendler wrote:
> I've got a stored proc that constructs some aggregation queries as strings
> and then executes them. I'd like to be able to increase work_mem before
> running those queries. If I set a new value for work_mem within the stored
> proc
19 matches
Mail list logo
