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
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.
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 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
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
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
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
