On May 16, 2011, at 8:47 AM, Merlin Moncure wrote:
> On Sat, May 14, 2011 at 5:10 AM, Stefan Keller wrote:
>> Hi,
>>
>> I am conducting a benchmark to compare KVP table vs. hstore and got
>> bad hstore performance results when the no. of records is greater than
>> about 500'000.
>>
>> CREATE TAB
Hi Jim
You actually made me think about the schema Michel and I are using:
> And KVP is? ;)
CREATE TABLE mykvpstore( id bigint PRIMARY KEY )
CREATE TABLE kvp ( id bigint REFERENCES mykvpstore(id), key text NOT
NULL, value text, );
-- with index on key
And the table with the associative array ty
On May 16, 2011, at 10:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, May 16, 2011 at 12:49 AM, Jesper Krogh wrote:
>>> Ok, it may not work as well with index'es, since having 1% in cache may very
>>> well mean that 90% of all requested blocks are there.. for tables in should
>>> be more
On Mon, May 16, 2011 at 01:54:06PM -0400, Jeff wrote:
> Yep - you need multiple threads to get max throughput of your io.
I am running:
~/pgiosim -c -b 100G -v -t4 file[0-9]*
Will each thread move 100GB of data? I am seeing:
158.69%, 4260 read, 0 written, 3407.64kB/sec 425.95 iops
2011/5/17 Scott Marlowe :
> On Tue, May 17, 2011 at 6:59 AM, Anibal David Acosta
> wrote:
>> Hello,
>>
>> How fillfactor impact performance of query?
>
> Fillfactor tells the db how much empty space to leave in the database
> when creating a table and inserting rows. If you set it to 90% then
>
On Tue, May 17, 2011 at 11:47 AM, Craig Ringer
wrote:
> On 05/17/2011 03:00 PM, Robert Klemme wrote:
>
>> The main point is that you do not benefit from the larger IO bandwidth
>> if access patterns do not permit parallel access to both disks (e.g.
>> because you first need to read index blocks in
On Tue, May 17, 2011 at 6:59 AM, Anibal David Acosta wrote:
> Hello,
>
> How fillfactor impact performance of query?
Fillfactor tells the db how much empty space to leave in the database
when creating a table and inserting rows. If you set it to 90% then
10% of the space in the table will be ava
Hello,
How fillfactor impact performance of query?
I have two cases,
One is a operational table, for each insert it have an update, this table
must have aprox. 1.000 insert per second and 1.000 update per second (same
inserted row)
Is necessary to change the fill factor?
The other case is a tab
2011/5/17 Craig Ringer :
> On 05/17/2011 03:00 PM, Robert Klemme wrote:
>
>> The main point is that you do not benefit from the larger IO bandwidth
>> if access patterns do not permit parallel access to both disks (e.g.
>> because you first need to read index blocks in order to know the table
>> bl
On 05/17/2011 03:00 PM, Robert Klemme wrote:
The main point is that you do not benefit from the larger IO bandwidth
if access patterns do not permit parallel access to both disks (e.g.
because you first need to read index blocks in order to know the table
blocks to read).
This makes me wonder
Hi,
>> select from t1 left join t2 WHERE id IN (select )
>
> Does it work as expected with one less join? If so, try increasing
> join_collapse_limit ...
That did the trick - thanks a lot. I only had to increase
join_collapse_limit a bit and now get an almost perfect plan.
Instead
On Mon, May 16, 2011 at 4:31 PM, Robert Haas wrote:
> On Mon, May 16, 2011 at 4:19 AM, Robert Klemme
> wrote:
>>> - If the planner chooses a Bitmap Index Scan, it effectively scans the
>>> index to figure out which table blocks to read, and then reads those
>>> table blocks in block number order,
12 matches
Mail list logo
