your pg adapter, it may open a transaction by default even
though it may not be required.
So please clarify whether this is the case.
Regards,
Julian.
On 20/09/13 10:49, Bartłomiej Romański wrote:
> Hi all
>
> We're experiencing a very strange performance issue. Our setup i
Filter: ((ord >= 5000) AND (ord <= 5500))
> Total runtime: 330.975 ms
>
> I havent found it on TODO or in archives so I'm wondering if this is a known
> behavior.
>
> Regards,
> Rikard
>
Hi,
Disregard the VIEW for the moment. (its not the issue here).
I wasn&#x
Hi
>>>>> "TL" == Tom Lane writes:
TL> b...@openit.de (Julian v. Bock) writes:
>> I have the problem that on our servers it happens regularly under a
>> certain workload (several times per minute) that all backend
>> processes get a SIGUSR1 and s
;t seem to
be an issue here.
Regards,
Julian v. Bock
--
Julian v. Bock Projektleitung Software-Entwicklung
OpenIT GmbH Tel +49 211 239 577-0
In der Steele 33a-41 Fax +49 211 239 577-10
D-40599 Düsseldorf http://www
u use some kind of connection pooling this can eat up a lot
of ram that could be used for caching instead.
Regards,
Julian
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
8.2 or later it should get better.
Isn't test 3 (scalar subqueries) also a nestloop-with-inner-indexscan with
an inner Append?
Julian
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
sub
ot;airport".
There's also a coarse filter applied (using bounding boxes and an rtree
index) as well as the expensive_function.
(And before anyone suggests it, I know this looks geospatial, but I don't
think PostGIS does what I need.)
Thanks
Julian
---
nction(g1.node, g2.node, some_table.node)
and other_table.route = 1
and other_table.start_id = g1.id
and other_table.end_id = g2.id;
So is there some way I can hint to the planner in q7 that superclass.id is
unique and that all it has to do is use superclass as an id -> node look
Gregory, thanks for all the insight! It is much appreciated.
Julian.
signature.asc
Description: This is a digitally signed message part.
Gregory Stark wrote:
> "Julian Mehnle" <[EMAIL PROTECTED]> writes:
> > I actually do have constraints on all the partitions, e.g. for week
> > 34: [...]
> >
> > Shouldn't this be enough to give the query planner a clue that it
> > only has to
the fault here.
>
> Try adding one record of data to each of those partitions or putting a
> constraint on them which will allow constraint_exclusion (I assume you
> have that enabled?) to kick in. You'll still be bitten by the parent
> table but hopefully that's not enough to cause a problem.
The parent table is empty. How will adding one record to each of the
partitions make a difference given the above constraints?
Julian.
signature.asc
Description: This is a digitally signed message part.
Julian Mehnle wrote:
> I have a large database with e-mail meta-data (no bodies) for over 100
> million messages. I am running PostgreSQL 8.2.4 on a server with 2GB
> of RAM (shared_buffers = 240MB, temp_buffers = 128MB, work_mem = 256MB,
> maintenance_work_mem = 256MB). I have the d
33)
-> Seq Scan on email_2007_week34_extras
(cost=0.00..491597.12 rows=26052512 width=33)
(7 rows)
Yes, I have `ANALYZE`d the database before running the queries.
How come the query planner gets thrown off that far by the simple table
partitioning? What can I do to put the query planner back on the right
track?
Julian.
signature.asc
Description: This is a digitally signed message part.
13 matches
Mail list logo
