fre 2016-07-22 klockan 19:08 +1200 skrev Mark Kirkwood:
> On 22/07/16 13:07, Johan Fredriksson wrote:
> > And by the way, I have also tried to upgrade to Postgresql 9.4.8 (the
> > latest version in postgresl.org's own repository) without improvment.
> >
>
> Not sure what repo you are using, but 9
On 22/07/16 13:07, Johan Fredriksson wrote:
And by the way, I have also tried to upgrade to Postgresql 9.4.8 (the latest
version in postgresl.org's own repository) without improvment.
Not sure what repo you are using, but 9.5.3 and 9.6 Beta are the
*actual* latest versions. Now I'm not sure
And by the way, I have also tried to upgrade to Postgresql 9.4.8 (the latest
version in postgresl.org's own repository) without improvment.
/ Eskil
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
I can add that setting enable_nestloop = 0 cuts the runtime for this query down
to about 4 seconds.
Disabling nested loops globaly does however impacts performance of a lot of
other queries.
/ Eskil
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make
On Thu, Jul 21, 2016 at 3:29 PM, David G. Johnston
wrote:
> On Thu, Jul 21, 2016 at 2:24 PM, Claudio Freire
> wrote:
>>
>> That cross join doesn't look right. It has no join condition.
>
>
> That is that the definition of a "CROSS JOIN"...
>
> David J.
Well, maybe it shouldn't be.
A cross join
On Thu, Jul 21, 2016 at 2:24 PM, Claudio Freire
wrote:
> That cross join doesn't look right. It has no join condition.
That is that the definition of a "CROSS JOIN"...
David J.
On Thu, Jul 21, 2016 at 11:48 AM, Johan Fredriksson wrote:
> EXPLAIN ANALYZE VERBOSE SELECT DISTINCT main.* FROM Users main CROSS
> JOIN ACL ACL_3 JOIN Principals Principals_1 ON ( Principals_1.id =
> main.id ) JOIN CachedGroupMembers CachedGroupMembers_2 ON
> ( CachedGroupMembers_2.MemberId = P
> > > The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
> > > Did you remember to ANALYZE all the tables after migrating? Maybe there
> > > were some table-specific statistics targets that you forgot to transfer
> > > over? In any case, the 9.2 plan looks like garbage-in-g
> > The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
> > Did you remember to ANALYZE all the tables after migrating? Maybe there
> > were some table-specific statistics targets that you forgot to transfer
> > over? In any case, the 9.2 plan looks like garbage-in-garbage-o
> > I am just about to upgrade from PostgreSQL 8.4.20 to 9.2.15, but I'v run
> > into some huge performance issues.
>
> The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
> Did you remember to ANALYZE all the tables after migrating? Maybe there
> were some table-specific st
>
> ...(BTW, I wonder why you are moving only to 9.2 and not something more
>> recent.)
>>
>
> Well, 9.2.15 is what comes bundled with RHEL 7, so I decided to go with
> that to avoid dependency issues. But I could install a more fresh version
> from scratch if that would solve my problem.
>
Genera
The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
Did you remember to ANALYZE all the tables after migrating? Maybe there
were some table-specific statistics targets that you forgot to transfer
over?
No, I did not. Honestly I though everything would be transfered with a
Johan Fredriksson writes:
> I am just about to upgrade from PostgreSQL 8.4.20 to 9.2.15, but I'v run
> into some huge performance issues.
The rowcount estimates from 9.2 seem greatly different from the 8.4 plan.
Did you remember to ANALYZE all the tables after migrating? Maybe there
were some ta
Hello!
I am just about to upgrade from PostgreSQL 8.4.20 to 9.2.15, but I'v run
into some huge performance issues. Both databases are configured the
same way (shared_buffers = 2GB, temp_buffers = 32MB). I have increased
work_mem on the 9.2 from 4MB to 64MB, but to no avail.
Now, the query on 8.4:
kling *EXTERN*'; 'Merlin Moncure'
Cc: 'postgres performance list'
Betreff: Re: [PERFORM] Performance problems with postgres and null Values?
Sven Kerkling wrote:
> This one ist the burden, running at least 100 seconds:
>
> SELECT b.id, b.status
>
Sven Kerkling wrote:
> This one ist the burden, running at least 100 seconds:
>
> SELECT b.id, b.status
> FROM export b, masterNew mb
> WHERE mb.sperre IS NULL
> AND mb.status IS NULL
> AND b.id = mb.id
> LIMIT 100;
>
> http://explain.depesz.com/s/eAqG
I think the pro
-performance-ow...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] Im Auftrag von Merlin Moncure
Gesendet: Samstag, 23. April 2016 00:11
An: Sven Kerkling
Cc: postgres performance list
Betreff: Re: [PERFORM] Performance problems with postgres and null Values?
On Thu, Apr 21, 2016 at 4:49 AM
On Thu, Apr 21, 2016 at 4:49 AM, Sven Kerkling wrote:
> Can somebody help me with these performance Problem.
>
> What can I try to solve this?
can you explain what the problem actually is? Which query is running
slow and how fast do you think it should run?
merlin
--
Sent via pgsql-performan
After remodeling a table we have some performance problems.
The Original tables have much more fields and we thought it came from these
many fields. After some testing I tried these test layout and the
performance problem is not solved.
Postgresql 9.3.12
Former DB-Layout was table _mast
"Sgarbossa Domenico" writes:
> I guess the right query is:
> select distinct on (articolo) articolo,data_ent,prezzo from
> listini_anagrafici order by articolo, data_ent desc
> but it seems that this query runs slowly... about 5/6 seconds.
> I've tried adding this index
> CREATE INDEX articol
The index can produce the sorted output. Add a dummy WHERE clause like
articoli > and data_ent > .
--Imad
On Mon, Sep 28, 2009 at 10:18 PM, Sgarbossa Domenico
wrote:
>
> I need to retrieve the most recent prices per products from a price list
> table:
>
> CREATE TABLE listini_anagrafici
> (
>
I need to retrieve the most recent prices per products from a price list table:
CREATE TABLE listini_anagrafici
(
id character varying(36) NOT NULL,
articolo character varying(18),
listino character varying(5),
data_ent date,
data_fin date,
prezzo double precision,
ultimo boolean DE
the parts
updated can allow a client application to merge the updates with a previous
full result client side.
On 9/29/09 5:44 AM, "Sgarbossa Domenico"
wrote:
> Subject: Re: [PERFORM] Performance problems with DISTINCT ON
>
>
>> Sgarbossa Domenico wrote:
>>>
> Should I try a different approach to solve this issue?
Yes. Ask yourself if you *really* need 180k rows.
Best regards,
depesz
--
Linkedin: http://www.linkedin.com/in/depesz / blog: http://www.depesz.com/
jid/gtalk: dep...@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007
--
Sent
Subject: Re: [PERFORM] Performance problems with DISTINCT ON
Sgarbossa Domenico wrote:
I need to retrieve the most recent prices per products from a price list
table:
select distinct on (articolo) articolo,data_ent,prezzo from
listini_anagrafici order by articolo, data_ent desc
but it
Sgarbossa Domenico wrote:
> I need to retrieve the most recent prices per products from a price list
> table:
> select distinct on (articolo) articolo,data_ent,prezzo from
> listini_anagrafici order by articolo, data_ent desc
>
> but it seems that this query runs slowly... about 5/6 seconds.
>
I need to retrieve the most recent prices per products from a price list table:
CREATE TABLE listini_anagrafici
(
id character varying(36) NOT NULL,
articolo character varying(18),
listino character varying(5),
data_ent date,
data_fin date,
prezzo double precision,
ultimo boolean DE
Rafael Martinez wrote:
> CPU 50% idle, rest mainly used in "system". Virtually no IO. No
> blocked processes. An impressive amount of context switches. No swap.
>
> An strace(1) of the postgres process may give a hint about the "system"
> part; this is what it does over and over and over agai
Tom Lane wrote:
> Rafael Martinez <[EMAIL PROTECTED]> writes:
>
>> Any ideas why it is taking 2462558.813 ms to finish when the total time
>> for the deletion is 2.546 ms + 3.422 ms + 0.603ms?
>
Hei Tom, I got this information from my colleague:
> Is the problem repeatable?
Repeatable as in
Rafael Martinez <[EMAIL PROTECTED]> writes:
> manage=# EXPLAIN ANALYZE DELETE FROM module WHERE deviceid='7298';
> QUERY PLAN
> -
> Nested Loop (cost=0.00..14.63 rows=1 width=67) (actual
> time=2.365..
Hello
---
Postgresql version: 8.1.10
4GB RAM
2x HP 72GB 10K SAS RAID1/smartarray
---
I have a colleague that is having som performance problems from time to
time when deleting some rows from a table.
We found out that the database having this probl
Thanks for your help Андрей your English is easily understandable and
much better than my ... (Russian?). I managed to get the results of an
analyze and this showed that an index was not being used correctly. It
seems that I was passing in a varchar and not casting it to an int and
this stopped
Thanks Euler,
I made the change to STABLE but it didn't seem to make any difference.
On closer inspection it seems to have been a casting problem, I was
passing a varchar into the function and then testing this for equality
with an integer. The planner seems to have been unable to use this t
Matthew Lunnon wrote:
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
$BODY$
LANGUAGE 'sql' VOLATILE;
^^
I suspect that it's because you're using VOLATILE (so no good
optimizations is done); did you try STABL
Ahh, sorry, I have been too aggressive with my cutting, I am running
8.2.6 and the function is below.
Thanks.
Matthew
CREATE OR REPLACE FUNCTION sp_get_price_panel_id(int4, "varchar",
"varchar", "varchar", bpchar)
RETURNS SETOF t_market_price_panel AS
$BODY$
SELECT *
FROM market mrkt
J
Matthew Lunnon wrote:
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
It depends. You'll need to show us the function.
Hi ms
I have a query which runs pretty quick ( 0.82ms) but when I put it
inside a stored procedure it takes 10 times as long (11.229ms). Is
this what you would expect and is there any way that I can get around
this time delay?
postgres.conf changes.
shared_buffers = 500MB
work_mem = 10MB
>>> On Fri, Oct 12, 2007 at 9:57 AM, in message
<[EMAIL PROTECTED]>, Theo Kramer
<[EMAIL PROTECTED]> wrote:
>
> select * from foo where
> (a = a1 and b = b1 and c >= c1) or
> (a = a1 and b < b1) or
> (a > a1)
> order by a, b desc, c;
>
> I have, however, found that transforming the above
On Fri, 2007-10-12 at 09:02 -0400, Merlin Moncure wrote:
> fwiw, I converted a pretty large cobol app (acucobol) to postgresql
> backend translating queries on the fly. if this is a fresh effort,
> you definately want to use the row-wise comparison feature of 8.2.
> not only is it much simpler, it
On 10/12/07, Theo Kramer <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
> > is this a converted cobol app?
>
> :) - on the right track - it is a conversion from an isam based package
> where I have changed the backed to PostgreSQL. Unfortunately there is
> w
Theo Kramer wrote:
On Thu, 2007-10-11 at 18:28 +, Andrew - Supernews wrote:
When you do this from the application, are you passing it 3 parameters,
or 5? The plan is clearly taking advantage of the fact that the two
occurrences of $1 and $2 are known to be the same value; if your app is
usi
On Thu, 2007-10-11 at 18:28 +, Andrew - Supernews wrote:
> On 2007-10-10, Theo Kramer <[EMAIL PROTECTED]> wrote:
> > When doing a 'manual' prepare and explain analyze I get the following
> >
> > rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
> > calllog_mainteng, calllog_phase
On Thu, 2007-10-11 at 13:28 -0400, Merlin Moncure wrote:
> On 10/11/07, Theo Kramer <[EMAIL PROTECTED]> wrote:
> > On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
> > > Theo Kramer wrote:
> > > >
> > > > So I suspect that there is something more fundamental here...
> > >
> > > OK, so there
On Thu, 2007-10-11 at 16:04 -0400, Merlin Moncure wrote:
> On 10/11/07, Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> > On 2007-10-10, Theo Kramer <[EMAIL PROTECTED]> wrote:
> > > When doing a 'manual' prepare and explain analyze I get the following
> > >
> > > rascal=# prepare cq (char(12), smal
On 10/11/07, Andrew - Supernews <[EMAIL PROTECTED]> wrote:
> On 2007-10-10, Theo Kramer <[EMAIL PROTECTED]> wrote:
> > When doing a 'manual' prepare and explain analyze I get the following
> >
> > rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
> > calllog_mainteng, calllog_phase,
On 2007-10-10, Theo Kramer <[EMAIL PROTECTED]> wrote:
> When doing a 'manual' prepare and explain analyze I get the following
>
> rascal=# prepare cq (char(12), smallint, integer) as SELECT oid,
> calllog_mainteng, calllog_phase, calllog_self FROM calllog
> WHERE calllog_mainteng = $1
> AND calllog
On 10/11/07, Theo Kramer <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
> > Theo Kramer wrote:
> > >
> > > So I suspect that there is something more fundamental here...
> >
> > OK, so there must be something different between the two scenarios. It
> > can only
On Thu, 2007-10-11 at 10:12 +0100, Richard Huxton wrote:
> Theo Kramer wrote:
> >
> > So I suspect that there is something more fundamental here...
>
> OK, so there must be something different between the two scenarios. It
> can only be one of:
>1. Query
> 2. DB Environment (user, locale, s
Theo Kramer wrote:
Thanks, had missed that, however, I am afraid that I fail to see how
preparing a query using PQprepare() and then executing it using
PQexecPrepared(), is 8 thousand times slower than directly executing
it.,, ( 403386.583ms/50.0ms = 8067 ).
When doing a 'manual' prepare and ex
Theo Kramer a écrit :
On Wed, 2007-10-10 at 17:00 +0200, Cédric Villemain wrote:
Reading the manual, you can learn that prepared statement can (not)
follow the same plan as direct query:
the plan is make before pg know the value of the variable.
See 'Notes' http://www.postgresql.org/doc
On Wed, 2007-10-10 at 15:55 -0400, Jonah H. Harris wrote:
> On 10/10/07, Theo Kramer <[EMAIL PROTECTED]> wrote:
> > When running the query directly from psql it returns the required rows
> > in less than 100 milli-seconds.
> >
> > However, when using a prepared statement from my C application on th
On 10/10/07, Theo Kramer <[EMAIL PROTECTED]> wrote:
> When running the query directly from psql it returns the required rows
> in less than 100 milli-seconds.
>
> However, when using a prepared statement from my C application on the
> above query and executing it the query duration is as follows
>
On Wed, 2007-10-10 at 17:00 +0200, Cédric Villemain wrote:
>
> Reading the manual, you can learn that prepared statement can (not)
> follow the same plan as direct query:
> the plan is make before pg know the value of the variable.
>
> See 'Notes' http://www.postgresql.org/docs/8.2/interactiv
Theo Kramer a écrit :
Hi
I have been having some serious performance issues when using prepared
statements which I can not re-produce when using a direct statement. Let
me try to explain
The query does an order by in descending order on several columns for
which an index exists.
The explain
Hi
I have been having some serious performance issues when using prepared
statements which I can not re-produce when using a direct statement. Let
me try to explain
The query does an order by in descending order on several columns for
which an index exists.
The explain output as follows
rascal
On 8/6/07, Sven Clement <[EMAIL PROTECTED]> wrote:
> Ok thanks everybody for the calrification, after all now I allready learned
> something new... ;)
>
> My employer is currently thinking about migration to 8.2.x because of your
> feedback, so I think that the problem could be resolved... ;)
Note
Ok thanks everybody for the calrification, after all now I allready learned
something new... ;)
My employer is currently thinking about migration to 8.2.x because of your
feedback, so I think that the problem could be resolved... ;)
Thanks to everyone...
Sven Clement
2007/8/6, Heikki Linnakanga
Sven Clement wrote:
> Partially I found that one in the PostgreSQL Documentation for the
> 7.x.xversions under the command REINDEX where they claim that you
> should run a
> reindex under certain circumstances and for my comprehension this says that
> with some access pattern (as ours (major writes
On mán, 2007-08-06 at 00:10 -0700, Sven Clement wrote:
>
>
> 2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
> I don't remember a bug like that. Where did you read that
> from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://ww
2007/8/5, Heikki Linnakangas <[EMAIL PROTECTED]>:
>
>
> I don't remember a bug like that. Where did you read that from?
>
> --
> Heikki Linnakangas
> EnterpriseDB http://www.enterprisedb.com
>
Partially I found that one in the PostgreSQL Documentation for the
7.x.xversions under the command
Sven Clement wrote:
> OK so beginning on Monday I will test the config on a 8.2.x to verify the
> performance issues, but I also found some disturbing info's on the net, that
> the index may be corrupted because of the big difference between an index
> entry which is deleted and the new value inser
Hi everybody,
The bigint problem was probably a typo because I had to type the entire
definitions, as the server is on a vpn and I don't had access with my
machine where I wrote the mail, and the 7.4.2 was surely a typo... ;) I
apology...
OK so beginning on Monday I will test the config on a 8.2.
Andrew Kroeger <[EMAIL PROTECTED]> writes:
> With the table definitions you posted, one of the first things I noticed
> was that the default value for an integer column was a bigint value. I
> did some quick 32-bit math and found that the smallest legal 32-bit
> integer value is -2147483648, not -
Sven Clement wrote:
> Table: "public.tmdata"
...
> id| integer | default -2147483684::bigint
...
> Table: "public.tmdataintervalsec"
...
> id| integer | default -2147483684::bigint
Not that this directly addresses the performance issues you described,
but
Sven,
> The hardware is a IBM X306m Server, 3.2 GHz HT (Pentium IV), 1 GB RAM
> and 2x 250 GB HDD (SATA-II) with ext3 fs, one of the HDD is dedicated to
> database. OS is Debian 3.1 Sarge with PostgreSQL 7.4.7 (7.4.7-6sarge1)
> with the libpq frontend library.
Note that 7.4.7 is not the current b
Hi,
First thank you already for your answers, as we are working in an
environment with NDA's I have first to check all the queries before I may
publish them here, but the structure of the DB is publishable:
2 Tables:
Table: "public.tmdata"
Column|Type |Modifiers
--
On 3 Aug 2007 at 6:52, Sven Clement wrote:
> Hello everybody,
>
> as I'm new to this list I hope that it is the right place to post this
> and also the right format, so if I'm committing an error, I apologize
> in advance.
>
> First the background of my request:
>
> I'm currently employed by an
On Fri, 2007-08-03 at 06:52 -0700, Sven Clement wrote:
> Hello everybody,
>
> as I'm new to this list I hope that it is the right place to post this
> and also the right format, so if I'm committing an error, I apologize
> in advance.
>
> First the background of my request:
>
> I'm currently em
Hello everybody,
as I'm new to this list I hope that it is the right place to post this and
also the right format, so if I'm committing an error, I apologize in
advance.
First the background of my request:
I'm currently employed by an enterprise which has approx. 250 systems
distributed worldwid
On Aug 31, 2006, at 3:08 PM, Tom Lane wrote:
Vivek Khera <[EMAIL PROTECTED]> writes:
Curious... See Message-ID: <[EMAIL PROTECTED]>
from the October 2003 archives. (I'd provide a full link to it, but
the http://archives.postgresql.org/pgsql-performance/ archives are
botched --
Still? I fou
Vivek Khera <[EMAIL PROTECTED]> writes:
> Curious... See Message-ID: <[EMAIL PROTECTED]>
> from the October 2003 archives. (I'd provide a full link to it, but
> the http://archives.postgresql.org/pgsql-performance/ archives are
> botched --
Still? I found it easily enough with a search for
On 31-Aug-06, at 2:15 PM, Vivek Khera wrote:
On Aug 30, 2006, at 7:48 PM, Dave Cramer wrote:
Actually unless you have a ram disk you should probably leave
random_page_cost at 4, shared buffers should be 2x what you have
here, maintenance work mem is pretty high
effective cache should be
On Aug 30, 2006, at 7:48 PM, Dave Cramer wrote:
Actually unless you have a ram disk you should probably leave
random_page_cost at 4, shared buffers should be 2x what you have
here, maintenance work mem is pretty high
effective cache should be much larger 3/4 of 4G or about 36
I've be
On Aug 30, 2006, at 12:26 PM, Jim C. Nasby wrote:
You misunderstand how effective_cache_size is used. It's the *only*
memory factor that plays a role in cost estimator functions. This
means
it should include the memory set aside for caching in shared_buffers.
Also, hibufspace is only talkin
On 30-Aug-06, at 10:10 AM, Vivek Khera wrote:
On Aug 30, 2006, at 5:29 AM, Matthew Sullivan wrote:
The hardware is a Compaq 6400r with 4G of EDO RAM, 4x500MHz Xeons
and a Compaq RAID 3200 in RAID 5 configuration running across 3
spindles (34G total space).
The OS is FreeBSD 5.4-RELEASE-
Matthew Sullivan wrote:
The OS is FreeBSD 5.4-RELEASE-p14
The PG Version is 8.1.3
Solutions/tips greatly appreciated.
This won't help this particular query, but 6.1-RELEASE will possibly be
a better performer generally, in particular for your SMP system - e.g.
the vfs layer is no longer u
Vivek Khera wrote:
On Aug 30, 2006, at 5:29 AM, Matthew Sullivan wrote:
The hardware is a Compaq 6400r with 4G of EDO RAM, 4x500MHz Xeons
and a Compaq RAID 3200 in RAID 5 configuration running across 3
spindles (34G total space).
The OS is FreeBSD 5.4-RELEASE-p14
The PG Version is 8.1.3
On Wed, 30 Aug 2006, Jim C. Nasby wrote:
> On Wed, Aug 30, 2006 at 10:10:28AM -0400, Vivek Khera wrote:
> > effective_cache_size = 27462# `sysctl -n
> > vfs.hibufspace` / 8192 (BLKSZ)
> > random_page_cost = 2
>
> You misunderstand how effective_cache_size is used. It's the *only*
> mem
On Wed, Aug 30, 2006 at 10:10:28AM -0400, Vivek Khera wrote:
> effective_cache_size = 27462# `sysctl -n
> vfs.hibufspace` / 8192 (BLKSZ)
> random_page_cost = 2
You misunderstand how effective_cache_size is used. It's the *only*
memory factor that plays a role in cost estimator functi
On Aug 30, 2006, at 5:29 AM, Matthew Sullivan wrote:
The hardware is a Compaq 6400r with 4G of EDO RAM, 4x500MHz Xeons
and a Compaq RAID 3200 in RAID 5 configuration running across 3
spindles (34G total space).
The OS is FreeBSD 5.4-RELEASE-p14
The PG Version is 8.1.3
What else does this
All,
Got a little bit of a performance problem I hope that can be resolved.
All the files/info I believe you are going to ask for are here:
http://www.au.sorbs.net/~matthew/postgres/30.8.06/
The odd thing was it originally was fast (1-2 seconds) which is all I
need - the query is a permission
Svenne Krap <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> where (flow_direction, dataset_id) in (select * from new_func(122))
> Is this form of multi-column IN mentioned anywhere in the docs? I can't
> find it.
Sure, look under "Subquery Expressions". 8.0 and later refer to it as a
row_const
Tom Lane wrote:
where (flow_direction, dataset_id) in (select * from new_func(122))
Is this form of multi-column IN mentioned anywhere in the docs? I can't
find it.
Svenne
smime.p7s
Description: S/MIME Cryptographic Signature
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, Mar 24, 2006 at 01:49:17PM +0100, Svenne Krap wrote:
>> explain select dataset_id, entity, sum(amount) from entrydata_current
>> where flow_direction in (select * from outflow_direction(dataset_id))
>> and dataset_id in (select * from get_data
On Fri, Mar 24, 2006 at 01:49:17PM +0100, Svenne Krap wrote:
> explain select dataset_id, entity, sum(amount) from entrydata_current
> where flow_direction in (select * from outflow_direction(dataset_id))
> and dataset_id in (select * from get_dataset_ids(122)) group by
> dataset_id, entity;
Hi there.
I have hit a edge in the planning and I hope you can help.
The system uses a lot of stored procedures to move as much of the
intelligence into the database layer as possible.
My (development) query looks like and runs reasonably fast:
explain analyze select dataset_id, entity, sum(
On Tue, 27 Dec 2005 19:02:17 +0100
Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
> Are there any "rules of thumb" to let a begginer give reasonable
> values to these parameters? Not only work_mem, but also
> random_page_cost, and so on. Are there any tests one can run to
> determine "good" value
A Dimarts 27 Desembre 2005 18:13, Michael Fuhr va escriure:
> On Tue, Dec 27, 2005 at 05:09:28PM +0100, Albert Cervera Areny wrote:
> > However, now we have a query that is much slower with 8.1 compared to
> > 7.4. The query lasts 7minutes (all the times we try) with 8.1, keeping
> > CPU usag
On Tue, Dec 27, 2005 at 05:09:28PM +0100, Albert Cervera Areny wrote:
> However, now we have a query that is much slower with 8.1 compared to
> 7.4.
> The query lasts 7minutes (all the times we try) with 8.1, keeping CPU usage
> at 93~97% while it lasts 25 seconds in 7.4 the first time goi
Hello,
we have a PostgreSQL for datawarehousing. As we heard of so many
enhancements
for 8.0 and 8.1 versions we dicided to upgrade from 7.4 to 8.1. I must say
that the COPY FROM processes are much faster now from 27 to 17 minutes. Some
queries where slower, but the performance problems
=?ISO-8859-1?Q?Dirk_Lutzeb=E4ck?= <[EMAIL PROTECTED]> writes:
> Here are the number of queries which the server has finished in a fix
> period of time.
Uh, you never actually supplied any numbers (or much of any other
specifics about what was tested, either).
My first reaction is "don't vary mor
Michael Stone wrote:
On Fri, Aug 05, 2005 at 01:11:31PM +0200, Dirk Lutzebäck wrote:
I will compile the latest PostgreSQL 8.1 snapshot for 32bit to
evaluate the new shared buffer code from Tom.
I think, the 64bit is slow because my queries are CPU intensive.
Have you actually tried it or
On Fri, Aug 05, 2005 at 01:11:31PM +0200, Dirk Lutzebäck wrote:
I will compile the latest PostgreSQL 8.1 snapshot for 32bit to evaluate
the new shared buffer code from Tom.
I think, the 64bit is slow because my queries are CPU intensive.
Have you actually tried it or are you guessing? If you'r
[[I'm
posting this on behalf of my co-worker who cannot post to this list at
the moment]]
Hi,
I had installed PostgreSQL on a 4-way AMD Opteron 875 (dual core) and
the performance isn't on the expected level.
Details:
The "old" server is a 4-way XEON MP 3.0 GHz with 4MB L3 cache, 32 GB
RA
Matthew Schumacher wrote:
> John A Meinel wrote:
>
>
>>Surely this isn't what you have. You have *no* loop here, and you have
>>stuff like:
>> AND
>>(bayes_token_tmp) NOT IN (SELECT token FROM bayes_token);
>>
>>I'm guessing this isn't your last version of the function.
>>
>>As far as putting
John A Meinel wrote:
> Surely this isn't what you have. You have *no* loop here, and you have
> stuff like:
> AND
> (bayes_token_tmp) NOT IN (SELECT token FROM bayes_token);
>
> I'm guessing this isn't your last version of the function.
>
> As far as putting the CREATE TEMP TABLE inside th
Matthew Schumacher wrote:
> Matthew Schumacher wrote:
>
>>Tom Lane wrote:
>>
>>
>>
>>>I don't really see why you think that this path is going to lead to
>>>better performance than where you were before. Manipulation of the
>>>temp table is never going to be free, and IN (sub-select) is always
>>>
Matthew Schumacher wrote:
> Tom Lane wrote:
>
>
>>I don't really see why you think that this path is going to lead to
>>better performance than where you were before. Manipulation of the
>>temp table is never going to be free, and IN (sub-select) is always
>>inherently not fast, and NOT IN (sub-
Tom Lane wrote:
> I don't really see why you think that this path is going to lead to
> better performance than where you were before. Manipulation of the
> temp table is never going to be free, and IN (sub-select) is always
> inherently not fast, and NOT IN (sub-select) is always inherently
> aw
John A Meinel <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't really see why you think that this path is going to lead to
>> better performance than where you were before.
> So for an IN (sub-select), does it actually pull all of the rows from
> the other table, or is the planner smart en
1 - 100 of 187 matches
Mail list logo
