Re: [PERFORM] Issues with \copy from file

2009-10-17 Thread Scott Marlowe
On Mon, Oct 12, 2009 at 4:05 PM, Sigurgeir Gunnarsson wrote: > I'm doing \copy from file into table. There are two files one with 7 million > lines and the other with around 24 million and the data goes into separate > table. There are only three columns in each file and four in each table (the >

Re: [PERFORM] Issues with \copy from file

2009-10-17 Thread Euler Taveira de Oliveira
Sigurgeir Gunnarsson escreveu: > What I'm wondering about is what parameters to tweak to improve the > operation and shorten the time of the \copy ? I think I have tweaked > most of the available in postgresql.conf, that is shared_buffer, > temp_buffers, work_mem, maintenance_work_mem, max_fsm_page

Re: [PERFORM] sequential scan on child partition tables

2009-10-17 Thread Scott Marlowe
On Thu, Oct 15, 2009 at 2:51 PM, Anj Adu wrote: > This appears to be a bug in the optimizer with resepct to planning > queries involving child partitions. It is clear that "any" index is > being ignored even if the selectivity is high. I had to re-write the > same query by explicitly "union-all" '

Re: [PERFORM] table full scan or index full scan?

2009-10-17 Thread Melton Low
I don't know if this will help. In my days with Oracle and Sybase, it use to work for both. Just give PG a hint like this select count(*) from test where id > 0; You can try it while you wait for other on the list with more knowledge for a different idea. Mel On Sun, Oct 11, 2009 at 4:26 AM,

Re: [PERFORM] Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

2009-10-17 Thread Scott Marlowe
On Sat, Oct 17, 2009 at 10:13 PM, Karl Denninger wrote: > Tory M Blue wrote: > > Also not real pain? A full dump and restore again, can't see that not being > > painful for a DB of any real size. > I am running Slony on 8.4; it complains on init but I have checked it > EXTENSIVELY and it is repli

Re: [PERFORM] table full scan or index full scan?

2009-10-17 Thread Euler Taveira de Oliveira
旭斌 裴 escreveu: > The postgresql database uses the table full scan.but in oracle, the > similar SQL uses the index full scanning,speed quickly many than > postgresql. > This was discussed many times on the pgsql mailing lists. Search the archives. Also, take a look at [1]. [1] http://wiki.postgr

Re: [PERFORM] Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

2009-10-17 Thread Karl Denninger
Tory M Blue wrote: > > Torsten Zühlsdorff wrote: > > > > > I've upgraded all my databases to 8.4. They pain was not so big, the > > new -j Parameter from pg_restore is fantastic. I really like the new > > functions around Pl/PGSQL. All is stable and fast. > > > > Greetin

Re: [PERFORM] Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

2009-10-17 Thread Tory M Blue
> Torsten Zühlsdorff wrote: > > > > > I've upgraded all my databases to 8.4. They pain was not so big, the > > new -j Parameter from pg_restore is fantastic. I really like the new > > functions around Pl/PGSQL. All is stable and fast. > > > > Greetings from Germany, > > Torsten > On Sat, Oct 17, 2

Re: [PERFORM] Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

2009-10-17 Thread Karl Denninger
Torsten Zühlsdorff wrote: > Tory M Blue schrieb: > >> Any issues, has it baked long enough, is it time for us 8.3 folks to >> deal >> with the pain and upgrade? > > I've upgraded all my databases to 8.4. They pain was not so big, the > new -j Parameter from pg_restore is fantastic. I really like th

Re: [PERFORM] Calculation of unused columns

2009-10-17 Thread Tom Lane
Robert Haas writes: > On Sat, Oct 17, 2009 at 9:41 PM, Tom Lane wrote: >> I've been thinking about this since your earlier mail, and I think it >> would probably be possible to suppress unused columns in a non-flattened >> subquery.  I remain unconvinced that it's worth the trouble though. >> A r

[PERFORM] Improving join performance over multiple moderately wide tables

2009-10-17 Thread miller_2555
Hi - I'm stuck on a query performance issue, and I would sincerely appreciate any server setting/ query improvement suggestions. I am attempting to retrieve records stored in 20 tables that are related to a one or more records in a single table (let's call the 20 tables `data tables` and the

Re: [PERFORM] Are folks running 8.4 in production environments? and 8.4 and slon 1.2?

2009-10-17 Thread Torsten Zühlsdorff
Tory M Blue schrieb: Any issues, has it baked long enough, is it time for us 8.3 folks to deal with the pain and upgrade? I've upgraded all my databases to 8.4. They pain was not so big, the new -j Parameter from pg_restore is fantastic. I really like the new functions around Pl/PGSQL. All i

[PERFORM] sequential scan on child partition tables

2009-10-17 Thread Anj Adu
Hi This query is doing a sequential scan on the child partitions even though indexes on all constrained columns are present The box is very lightly loaded (8 core 15K 6x300G Raid 10 disks) explain analyze select thedate,sent.theboxid_id,sub_box_id,box_num,sum(summcount) as event_count,'ACC'

Re: [PERFORM] Indexes on low cardinality columns

2009-10-17 Thread Vikul Khosla
Thanks Greg!. Yes, we do need to query on all 3000 values ... potentially. Considering that when we changed the B-Tree indexes to Bitmap indexes in Oracle we saw a huge performance boost ... doesn't that suggest that absence of this feature in PG is a constraint ? Are there any other clever worka

[PERFORM] Issues with \copy from file

2009-10-17 Thread Sigurgeir Gunnarsson
I'm doing \copy from file into table. There are two files one with 7 million lines and the other with around 24 million and the data goes into separate table. There are only three columns in each file and four in each table (the primary key, id serial is the fourt). The data is about 150 MB and 450

[PERFORM] Performance with sorting and LIMIT on partitioned table

2009-10-17 Thread Michal Szymanski
We have performance problem with query on partitioned table when query use order by and we want to use first/last rows from result set. More detail description: We have big table where each row is one telephone call (CDR). Definitnion of this table look like this: CREATE TABLE accounting.cdr_full_p

Re: [PERFORM] Partitioned Tables and ORDER BY

2009-10-17 Thread Michal Szymanski
I've described our problem here http://groups.google.pl/group/pgsql.performance/browse_thread/thread/54a7419381bd1565?hl=pl# Michal Szymanski http://blog.szymanskich.net http://techblog.freeconet.pl/ -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes t

Re: [PERFORM] Domain vs table

2009-10-17 Thread Michal Szymanski
I think I've found answer to my question http://www.commandprompt.com/blogs/joshua_drake/2009/01/fk_check_enum_or_domain_that_is_the_question/ Michal Szymanski -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresq

[PERFORM] Domain vs table

2009-10-17 Thread Michal Szymanski
Hi, We have table 'user' and one column define status of user, currently there are 2 valuse 'A' acitve and 'D' deleted. Currently we define column as domain type ( status_domain with two possible values) but I'm not sure is it good solution, maybe it is better create separate table e.g account_sta

[PERFORM] table full scan or index full scan?

2009-10-17 Thread 旭斌 裴
I have a 30,000,000 records table, counts the record number to need for 40 seconds. The table has a primary key on column id; perf=# explain select count(*) from test; ... - Aggregate (cost=603702.80..603702.81 rows=1 width=0)   -> Seq scan on test (cost=

Re: [PERFORM] Partitioned Tables and ORDER BY

2009-10-17 Thread Michal Szymanski
We have similar problem and now we are try to find solution. When you execute query on partion there is no sorting - DB use index to retrieve data and if you need let say 50 rows it reads 50 rows using index. But when you execute on parent table query optymizer do this: -> Sort (cost=726844.88

Re: [PERFORM] Calculation of unused columns

2009-10-17 Thread Robert Haas
On Sat, Oct 17, 2009 at 9:41 PM, Tom Lane wrote: > I've been thinking about this since your earlier mail, and I think it > would probably be possible to suppress unused columns in a non-flattened > subquery.  I remain unconvinced that it's worth the trouble though. > A real (not handwavy) example

Re: [PERFORM] Calculation of unused columns

2009-10-17 Thread Tom Lane
[ please keep the list cc'd ] Volker Grabsch writes: > The "count(*)" in the example seems to be distracting. In fact, > it could be replaced with a simple constant value, the effect > is the same: > CREATE VIEW a AS > SELECT > (... expensive calculation ...) as expensive, >

Re: [PERFORM] Calculation of unused columns

2009-10-17 Thread Tom Lane
Volker Grabsch writes: > I'm confused about the absence of a very simple optimization > in PostgreSQL. Suppose we have a VIEW where some columns are > expensive to be calculated: > CREATE VIEW a AS > SELECT > (... expensive calculation ...) as expensive, > count(*) as chea

[PERFORM] Calculation of unused columns

2009-10-17 Thread Volker Grabsch
Dear PostgreSQL developers, I'm confused about the absence of a very simple optimization in PostgreSQL. Suppose we have a VIEW where some columns are expensive to be calculated: CREATE VIEW a AS SELECT (... expensive calculation ...) as expensive, count(*) as cheap FRO

Re: [PERFORM] Indexes on low cardinality columns

2009-10-17 Thread Jeff Janes
On Sat, Oct 17, 2009 at 10:02 AM, Vikul Khosla wrote: > > Thanks Greg!. > > Yes, we do need to query on all 3000 values ... potentially. Considering > that when we changed the B-Tree indexes to Bitmap indexes in Oracle > we saw a huge performance boost ... doesn't that suggest that absence of > th

Re: [PERFORM] Indexes on low cardinality columns

2009-10-17 Thread Robert Haas
On Sat, Oct 17, 2009 at 1:02 PM, Vikul Khosla wrote: > > Thanks Greg!. > > Yes, we do need to query on all 3000 values ... potentially. Considering > that when we changed the B-Tree indexes to Bitmap indexes in Oracle > we saw a huge performance boost ... doesn't that suggest that absence of > thi

Re: [PERFORM] Indexes on low cardinality columns

2009-10-17 Thread Vikul Khosla
Thanks Greg!. Yes, we do need to query on all 3000 values ... potentially. Considering that when we changed the B-Tree indexes to Bitmap indexes in Oracle we saw a huge performance boost ... doesn't that suggest that absence of this feature in PG is a constraint ? Are there any other clever wor