Hi thank you for such a useful information... but actually in my case if i keep table in disk it significantly
degrades performance and even for a table of 10 rows it takes 1-2
minutes I think u r not beliving it ! am i right
for example
I create a table in which i use my customized data type say student
create table student
(Name INDCHAR //INDCHAR is customized data type age integer);
now i give query like this
select * from student order by name;
it will search for it's comparator operator (<) and related function...
in that function there is one lookup table if that table is in memory no
problem! (oh but it can't be) if it is in disk my program makes
connection to database and execute query which is just a select
statement on a simple where condition of equality. then closes connection
so every time less than operator(<) is called it does the same task..
what i feel in table of 10 rows how many times the < operator will be
called(NO idea but must be > 10 times)
is there any solution..
thanks in advance
regards
vinay
scott.marlowe wrote:
>On Wed, 21 Apr 2004 vinayj@ncst.ernet.in wrote:
>
>
>
>>Hi
>>I am working on a project in postgres..in which i designed customized data type
>>and operations on it.it requires a look up table..
>>I have three options regarding this table...
>>1. Every time a query is executed it creates table assigns values and after
>>execution destroys it...which is overhead..
>>
>>2. store table on disk in database and access it whenever required but it
>>degrades the performance
>>
>>3. whenever psql starts it can load the table in memory from database which is
>>efficient way to do
>>
>>
>
>PostgreSQL has no facility to put tables into memory.
>
>Assuming this lookup table will be hit quite often, it WILL be in memory
>for selects. updates / deletes / inserts will have to get flushed out to
>disk of course.
>
>the Linux and BSD kernels are both quite good at keeping commonly used
>data in memory. I think you are mistaken in assuming that an "on disk"
>table will be significantly slower than if it was fixed in memory due to
>the very efficient cachine of the most common unix kernels.
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
>