Robins Tharakan writes:
> ORIGINAL QUERY (on PostgreSQL 8.4.9):
> http://explain.depesz.com/s/bTm
> EXPLAIN ANALYZE SELECT field_a FROM large_table_a JOIN large_table_b
> USING (field_a) WHERE field_b IN (SELECT large_table_b.field_b FROM
> large_table_b WHERE field_a = 2673056) ;
> --
"Jens Reufsteck" writes:
> Ive got a lengthy query, that doesn't finish in reasonable time (i.e.
> 10min+). I suspect, that the query optimizer miscalculates the number of
> rows for part of the query.
> ...
> We're using postgres 9.0.4.
Try 9.0.5. There was a bug fixed in this area.
Hi,
On Wednesday 26 Oct 2011 14:43:08 Cezariusz Marek wrote:
> Is there any known problem with slow cursors in PostgreSQL 8.4.5?
>
> I have a following query, which is slow (on my database it takes 11 seconds
> to execute), probably should be rewritten, but it doesn't matter here. The
> problem i
Gregg Jaskiewicz wrote:
> Do you really need to query the catalogues ? That on its own is not a
> good idea if you want something to run fast and frequently.
I know, but I've used it just to show the problem with cursors. I have the same
problem
with other slow queries, which execute within x sec
El 26/10/11 14:23, Merlin Moncure escribió:
> On Wed, Oct 26, 2011 at 4:00 AM, Linos wrote:
>> El 25/10/11 19:11, Merlin Moncure escribió:
>>> On Tue, Oct 25, 2011 at 11:47 AM, Linos wrote:
El 25/10/11 18:43, Tom Lane escribió:
> Linos writes:
>> i am having any problems with pe
Do you really need to query the catalogues ? That on its own is not a
good idea if you want something to run fast and frequently.
--
GJ
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-p
Is there any known problem with slow cursors in PostgreSQL 8.4.5?
I have a following query, which is slow (on my database it takes 11 seconds to
execute),
probably should be rewritten, but it doesn't matter here. The problem is, that
in cursor,
each fetch takes much longer (even few minutes!),
On Wed, Oct 26, 2011 at 4:00 AM, Linos wrote:
> El 25/10/11 19:11, Merlin Moncure escribió:
>> On Tue, Oct 25, 2011 at 11:47 AM, Linos wrote:
>>> El 25/10/11 18:43, Tom Lane escribió:
Linos writes:
> i am having any problems with performance of queries that uses CTE,
> can the
Ive got a lengthy query, that doesn't finish in reasonable time (i.e.
10min+). I suspect, that the query optimizer miscalculates the number of
rows for part of the query.
The suspicious subquery:
SELECT
sv1.sid as sid
FROM stud_vera sv1
El 25/10/11 19:11, Merlin Moncure escribió:
> On Tue, Oct 25, 2011 at 11:47 AM, Linos wrote:
>> El 25/10/11 18:43, Tom Lane escribió:
>>> Linos writes:
i am having any problems with performance of queries that uses CTE,
can the
join on a CTE use the index of the original table
Hello, Alan
On 2011.10.25 17:12, alan wrote:
I'm new to postgres and was wondering how to use EXPLAIN ANALYZE
Can I use the output from ANALYZE EXPLAIN to estimate or predict the
actual time
it would take for a given query to return?
Explain analyze executes the query, so you get the actua
11 matches
Mail list logo
