On 2015-12-17 16:23, Tom Lane wrote:
Mikkel Lauritsen 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 266177 rows.
The application
e various statistics related knobs seems to 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 welcom
x_a_id_idx on x (cost=0.00..374.95 rows=6059
width=86) (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 subsc
Hi all,
On Wed, 11 Sep 2013 18:55:38 +0200, Giuseppe Broccolo
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 ser
erformance 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 JO
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.
make the first query execute as fast as
the second one.
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 en
