Re: [PERFORM] Planner question - "bit" data types

Bruce Momjian wrote: > Karl Denninger wrote: > >>> Yes. In addition, functions that are part of expression indexes do get >>> their own optimizer statistics, so it does allow you to get optimizer >>> stats for your test without having to use booleans. >>> >>> I see this documented in the 8.0 re

Re: [PERFORM] Planner question - "bit" data types

Bruce Momjian wrote: > > Interesting... declaring this: > > > > create function ispermitted(text, integer) returns boolean as $$ > > select permission & $2 = permission from forum where forum.name=$1; > > $$ Language SQL STABLE; > > > > then calling it with "ispermitted(post.forum, '4')" as one o

Re: [PERFORM] Planner question - "bit" data types

Karl Denninger wrote: > > Yes. In addition, functions that are part of expression indexes do get > > their own optimizer statistics, so it does allow you to get optimizer > > stats for your test without having to use booleans. > > > > I see this documented in the 8.0 release notes: > > > > *

Re: [PERFORM] Planner question - "bit" data types

Bruce Momjian wrote: > Alvaro Herrera wrote: > >> Karl Denninger escribi?: >> >> >>> The individual boolean fields don't kill me and in terms of some of the >>> application issues they're actually rather easy to code for. >>> >>> The problem with re-coding for them is extensibility (by thos

Re: [PERFORM] Planner question - "bit" data types

Alvaro Herrera wrote: > Karl Denninger escribi?: > > > The individual boolean fields don't kill me and in terms of some of the > > application issues they're actually rather easy to code for. > > > > The problem with re-coding for them is extensibility (by those who > > install and administer the

Re: [PERFORM] Use of BETWEEN with identical values

André Volpato escreveu: (...) (Postgres 8.3.6, Debian Linux 2.6.18-6-amd64) (...) Condition 1: # select fat_referencia from bds_contratacao_fatura where fat_referencia BETWEEN 200908 AND 200908; Index Scan using ibds_contratacao_fatura1 on bds_contratacao_fatura (cost=0.00..5.64 rows=1 wi

[PERFORM] Use of BETWEEN with identical values

Hi, Is there any downsides of using BETWEEN two identical values ? (Postgres 8.3.6, Debian Linux 2.6.18-6-amd64) The problem is in this index: CREATE INDEX ibds_contratacao_fatura1 ON bds_contratacao_fatura USING btree (fat_referencia); "fat_referencia" is a field that tells year and month

Re: [PERFORM] optimizing for temporal data behind a view

Hi Richard, > CREATE VIEW geodataview AS SELECT obstime + (s.a*5 || ' > seconds')::INTERVAL AS obstime, statid, geovalue_array[s.a+1][1] AS > x_mag, geovalue_array[s.a+1][2] AS y_mag, geovalue_array[s.a+1][3] AS > z_mag FROM generate_series(0, 11) AS s(a), geodata1sec; To my (admittedly untrained

Re: [PERFORM] Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?

Vlad Romascanu wrote: Problem occurs when running (in production) Postgres 8.3.7 64-bit (from RPM) on Ubuntu 8.04.2, on an Amazon EC2 (xen) "Large" instance (8GB RAM), with the DB on a 50GB EC2 block device. Problem does not occur when running (in staging/pre-production) Postgres 8.3.5 32-bit (

Re: [PERFORM] statistical table

On Tue, Sep 15, 2009 at 02:27:41AM -0700, std pik wrote: > Hello all.. > I'm using PostgreSQL 8.3.. > How can I get information about the hardware utilization: > - CPU usage. > - Disk space. > - Memory allocation. > thank you. In general, use the utilities provided by your

Re: [PERFORM] statistical table

--- On Tue, 9/15/09, std pik wrote: From: std pik Subject: [PERFORM] statistical table To: pgsql-performance@postgresql.org Date: Tuesday, September 15, 2009, 9:27 AM Hello all.. I'm using PostgreSQL 8.3.. How can I get information about the hardware utilization:         - CPU usage.         -

[PERFORM] optimizing for temporal data behind a view

Hi All, I have a large quantity of temporal data, 6 billion rows, which I would like to put into a table so I can exploit SQL datetime queries. Each row represents a geophysical observation at a particular time and place. The data is effectively read-only - i.e. very infrequent updates will be per

Re: [PERFORM] noapic option

On Mon, 2009-09-14 at 14:48 -0700, C Storm wrote: > In this linux mag article (http://www.linux-mag.com/cache/7516/1.html) > the author describes a performance problem > brought on by using the noapic boot time kernel option. Has anyone > investigated whether postgres performs better > with/withou

Re: [PERFORM] Possible causes of sometimes slow single-row UPDATE with trivial indexed condition?

Vlad Romascanu wrote: > Problem occurs when running (in production) Postgres 8.3.7 64-bit (from > RPM) on Ubuntu 8.04.2, on an Amazon EC2 (xen) "Large" instance (8GB > RAM), with the DB on a 50GB EC2 block device. Hmm - don't know what the characteristics of running PG on EC2 are. This might be so