I will gather the other data tonight. Thank you.
In the meantime, I guess I wasn't clear about some other particulars
The query's where clause is only an "IN", with a list of id's (those I mentioned are the PK), and the join is explicitly on the PK (so, indexed).
Thus, there should be only the explicit matches to the in clause returned, and if postgresql isn't using the unique index on that column, I would be very shocked (to the point I would suggest there is a bug somewhere).
An IN with 50 int values took 23sec to return (by way of example).
Thanks again.
--
Aaron
On June 25, 2014 4:49:16 PM EDT, Shaun Thomas <sthomas@optionshouse.com> wrote:
On 06/25/2014 03:10 PM, AJ Weber wrote:
I have a relatively sizable postgresql 9.0.2 DB with a few large tables
(keep in mind "large" is relative, I'm sure there are plenty larger out
there).
Regardless of any help we might offer regarding this, you need to
upgrade your installation to 9.0.17. You are behind by several
performance, security, and integrity bugfixes, some of which address
critical corruption bugs related to replication.
One of my queries that seems to be bogging-down performance is a join
between two tables on each of their BIGINT PK's (so they have default
unique constraint/PK indexes on them). One table is a detail table
for
the other.
This isn't enough information. Just knowing the relative sizes of the
tables doesn't tell us which columns are indexed, whether or not the
query is using those indexes, how many rows usually match, which queries
are performing badly, and so on.
Please refer to this page to ask performance related questions:
https://wiki.postgresql.org/wiki/Slow_Query_Questions
Without much of this information, we'd only be speculating.
