calculating costs.

From: Tzahi Fadida <tzahi_ml(at)myrealbox(dot)com>
To: pgsql-general(at)postgresql(dot)org
Subject: calculating costs.
Date: 2005-01-05 02:10:52
Message-ID: 006101c4f2cb$ce2683d0$0b00a8c0@llord
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all,
I am doing experiments on a new operator I am writing as a C shared
library function.
1) As part of the experimentation I need to know exactly how many blocks
have been read/write when
the algorithm ran. I need complete control over the process to run my
simulations.
I see that there are functions like heap heap_getnext() heap_fetch()
SearchSysCache().
Our algorithm usually read sequentially the relations and I don't see
how to read complete blocks and
count these blocks. In addition temporary queues that must be held in
memory will be needed to be dumped to
disk at various times (because of their size) and fetched. Is there a
way to control this process
with accuracy and calculate the exact disk writes?
2) As part of the theoretical work and experimentation we want to load
blocks of relation rows to the
main memory and cache them using our techniques. Is there a way to
control the memory blocks so
they won't be swapped. In addition, is there a way to get a specific
size of memory so we can
plan our operator running path. I see that palloc return's to me a
chunck of memory but I don't know
in advance how much is available to me (aside from polling for it).

P.S: I tried EXPLAIN ANALYZE but I don't think it actually counts
exactly the blocks.

Thank you.

Regards,
tzahi.

* - * - *
Itzhak Fadida
MSc Student
Information System Engineering Area
Faculty of Industrial Engineering & Management
Technion - Israel Institute of Technology
Technion City, Haifa, Israel 32000
Technion Email: Tzahi(at)TX(dot)Technion(dot)ac(dot)il
Alternative Email: TzahiFadida(at)MyRealBox(dot)com
* - * - * - * - * - * - * - * - * - * - * - * - * - * - *

WARNING TO SPAMMERS: see at
http://members.lycos.co.uk/my2nis/spamwarning.html

Browse pgsql-general by date

  From Date Subject
Next Message Stuart Bishop 2005-01-05 08:01:30 Re: PostgreSQL 8.0.0 Release Candidate 3
Previous Message Lonni J Friedman 2005-01-05 00:27:26 Re: vacuum is failing