o make no difference, but is
there be some other way I can make Postgres assume high selectivity for
certain tag values? Am I just SOL with the given schema?
Any pointers to information about how to handle potentially lopsided
data like this are highly welcome.
Best regards,
Mikkel Lauritsen
--
Se
On 2015-12-17 16:23, Tom Lane wrote:
Mikkel Lauritsen <ren...@tala.dk> writes:
The schema contains two tables, t1 and t2.
t2 has two fields, an id and a tag, and it contains 146 rows that are
unique.
t1 has two fields, a value and a foreign key referring to t2.id, and
it
contains 26617
) (actual time=0.055..27.219 rows=32863 loops=1)
Index Cond: (a_id = a.id)
Best regards thanks,
Mikkel Lauritsen
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
difference is perfectly
reasonable as the outer loop has to process 3576 rows in the fast case and
154149 rows in the slow case.
Best regards thanks,
Mikkel Lauritsen
---
Query:
SELECT x.r, e.id, a.id
FROM x
INNER JOIN e ON x.id = e.id
INNER JOIN a ON x.a_id = a.id
INNER JOIN i ON a.i_id = i.id
Hi all,
On Wed, 11 Sep 2013 18:55:38 +0200, Giuseppe Broccolo
giuseppe.brocc...@2ndquadrant.it wrote:
Il 11/09/2013 13:16, Mikkel Lauritsen ha scritto:
Hi all,
I have a number of Postgres 9.2.4 databases with the same schema but
with slightly different contents, running on small servers
.
I'm more specifically thinking whether I'm missing out on a crucial
planner
configuration knob or something like that, which causes the planner to
treat the two cases differently.
Best regards thanks for an excellent database engine,
Mikkel Lauritsen
--
Sent via pgsql-performance mailing
Hi Tom et al,
Many thanks for your prompt reply - you wrote:
SELECT * FROM table t1 WHERE 0 = (SELECT COUNT(*) FROM table t2 WHERE
t2.type = t1.type AND t2.timestamp t1.timestamp)
I suspect that *any* database is going to have trouble optimizing that.
Okay, I expected that much.
Just
