[GENERAL] prepared statement functioning range

Hello everybody: Sorry for disturbing. I experience the prepared statement of postgresql via psql and have one question: In terminal A: I prepared: postgres=# prepare test(int) AS postgres-# select * from customers c where c.cust_id = $*1*; PREPARE postgres=# Then run: postgres=# e

Re: [GENERAL] prepared statement functioning range

高健 wrote: > Prepared statement is only for use in the same session at which it has been > executed. > It can not be shared via multiple sessions. That is correct, see http://www.postgresql.org/docs/current/static/sql-prepare.html > That is, when in some special situations , > if I have to use

Re: [GENERAL] Why hash join cost calculation need reduction

* 高健 (luckyjack...@gmail.com) wrote: [...] > postgres=# explain analyze select * from sales s inner join customers c on > s.cust_id = c.cust_id and c.cust_id =2; [...] > When I use the where condition such as , > > postgresql is clever enough to know it is better to make seqscan and > filter ?

Re: [GENERAL] prepared statement functioning range

* 高健 (luckyjack...@gmail.com) wrote: > So I can draw a conclusion: > > Prepared statement is only for use in the same session at which it has > been executed. Prepared statements are session-local. > It can not be shared via multiple sessions. Correct. > That is, when in some special situati

Re: [GENERAL] PSA: If you are running Precise/12.04 upgrade your kernel.

On 06/06/13 15:35, Joshua D. Drake wrote: > > I had the distinct displeasure of staying up entirely too late with a > customer this week because they upgraded to 12.04 and immediately > experienced a huge performance regression. In the process they also > upgraded to PostgreSQL 9.1 from 8.4. Th

Re: [GENERAL] PSA: If you are running Precise/12.04 upgrade your kernel.

On 06/14/2013 09:12 AM, Bosco Rama wrote: A colleague mentioned this LKML thread: Seems it was fixed in 3.9.x. I'm wonder if there is any way to easily determine if the fix was back-ported to the various Ubunutu-maintained

[GENERAL] Can't increase shared_buffers for PostgreSQL on openSUSE 12.3

Hi I just installed an openSUSE 12.3 64Bit on an i5 box with 32GB RAM. Then I installed postgresql 9.2.4 from their repository. The pg service starts with default config. As default it has only 24 MB shared_buffers. I need it way higher like 4 or even 8 GB. As soon I change those 24 MB to somet

Re: [GENERAL] Can't increase shared_buffers for PostgreSQL on openSUSE 12.3

On Fri, Jun 14, 2013 at 11:55 AM, Andreas wrote: > How can I get more memory for PG on openSUSE 12.3 ? http://www.postgresql.org/docs/9.2/static/kernel-resources.html -- Regards, Peter Geoghegan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your su

Re: [GENERAL] Can't increase shared_buffers for PostgreSQL on openSUSE 12.3

Am 14.06.2013 20:55, schrieb Peter Geoghegan: On Fri, Jun 14, 2013 at 11:55 AM, Andreas wrote: How can I get more memory for PG on openSUSE 12.3 ? http://www.postgresql.org/docs/9.2/static/kernel-resources.html OK I think that did it :) I'm just wondering what point it could be to set t

Re: [GENERAL] Can't increase shared_buffers for PostgreSQL on openSUSE 12.3

On 06/14/2013 01:47 PM, Andreas wrote: Am 14.06.2013 20:55, schrieb Peter Geoghegan: On Fri, Jun 14, 2013 at 11:55 AM, Andreas wrote: How can I get more memory for PG on openSUSE 12.3 ? http://www.postgresql.org/docs/9.2/static/kernel-resources.html OK I think that did it :) I'm just

[GENERAL] could not write to hash-join temporary file: No space left on device

My database is total around 100 gigs of data, and I have 50 gigs free on the volume, yet I get this error message. It was a simple join. Is there a way to see more information on why I got this error? -- Moshe Jacobson Nead Werx, Inc. | Manager of Systems Engineering 2323 Cumberland Parkway, Suit

Re: [GENERAL] Can't increase shared_buffers for PostgreSQL on openSUSE 12.3

On Sat, Jun 15, 2013 at 5:46 AM, Joshua D. Drake wrote: > The type of shared memory postgresql uses is rarely used by other systems. > However, as I recall 9.3 resolves the shmmax issue as a whole so it won't > be a problem. > Yes, by reducing system v shared memory consumption: http://git.postgre