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
>
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
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" '
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,
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
旭斌 裴 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
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
> 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
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
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
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
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
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'
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
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
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
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
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
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
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=
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
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
[ 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,
>
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
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
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
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
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
28 matches
Mail list logo