x=2147483648
> kern.ipc.semmap=512
> kern.ipc.shm_use_phys=1
>
> And the last one is the loader.conf from BSD, which are relevant for theese
> postgre settings:
> kern.ipc.semmni=512
> kern.ipc.semmns=1024
> kern.ipc.semmnu=512
>
> Theese settings based on my experien
;
> Derrick
>
>
> On Fri, May 27, 2011 at 3:36 PM, preetika tyagi
> wrote:
>
>> Hi All,
>>
>> I am little confused about the internal working of PostgreSQL. There is a
>> parameter shared_buffer in postgres.conf and I am assuming that it is used
>> fo
Hi All,
I am little confused about the internal working of PostgreSQL. There is a
parameter shared_buffer in postgres.conf and I am assuming that it is used
for buffer management in PostgreSQL. If there is a need to bring in a new
page in the buffer and size exceeds the shared_buffer limit, a vict
, Mar 21, 2011 at 9:06 AM, Scott Ribe wrote:
> On Mar 21, 2011, at 9:55 AM, preetika tyagi wrote:
>
> > For example, if A is 15 minutes, then B is 1.5 hrs.
>
> Well, considering that random disk access is on the order of 10,000 times
> slower than RAM...
>
> But you can a
wrote:
>
> On Mar 21, 2011, at 10:42 AM, preetika tyagi wrote:
>
> > Query: INSERT INTO table1 SELECT * FROM table2.
> > Execution Time: A ms.
> >
> > Query: INSERT INTO table1 SELECT * FROM table2.
> > Execution Time: B ms
>
> If session is sa
Hi,
I am wondering if someone can help me understand the following query
execution behavior:
I have two similar tables and table2 consists of 500 records.
Query: INSERT INTO table1 SELECT * FROM table2.
Execution Time: A ms.
Query: INSERT INTO table1 SELECT * FROM table2.
Execution Time: B
