Databases
StackOverflow2013
Postsdbo
POErratic indexed query performance in PostgreSQL
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POErratic indexed query performance in PostgreSQL
    primarykey
    data
    text
    <p>Need help regarding performance of a query in PostgreSQL. It seems to relate to the indexes.</p> <p>This query:</p> <ul> <li>Filters according to <code>type</code></li> <li>Orders by <code>timestamp</code>, ascending:</li> </ul> <p><code>SELECT * FROM the_table WHERE type = 'some_type' ORDER BY timestamp LIMIT 20</code></p> <p>The Indexes:</p> <pre><code> CREATE INDEX the_table_timestamp_index ON the_table(timestamp); CREATE INDEX the_table_type_index ON the_table(type); </code></pre> <p>The values of the <code>type</code> field are only ever one of about 11 different strings.<br> The problem is that the query seems to execute in O(log n) time, taking only a few milliseconds most times except for some values of <code>type</code> which take on the order of several minutes to run.</p> <p>In these example queries, the first takes only a few milliseconds to run while the second takes over 30 minutes:</p> <pre><code>SELECT * FROM the_table WHERE type = 'goq' ORDER BY timestamp LIMIT 20 SELECT * FROM the_table WHERE type = 'csp' ORDER BY timestamp LIMIT 20 </code></pre> <p>I suspect, with about 90% certainty, that the indexes we have are not the right ones. I think, after reading <a href="https://stackoverflow.com/questions/6174565/why-does-the-following-postgres-sql-query-take-so-long">this similar question about index performance</a>, that most likely what we need is a composite index, over <code>type</code> and <code>timestamp</code>.</p> <p>The query plans that I have run are here:</p> <ol> <li><a href="http://explain.depesz.com/s/i34" rel="nofollow noreferrer">Expected performance, type-specific index (i.e. new index with the type = 'csq' in the <code>WHERE</code> clause</a>).</li> <li><a href="http://explain.depesz.com/s/pix" rel="nofollow noreferrer">Slowest, problematic case, indexes as described above.</a></li> <li><a href="http://explain.depesz.com/s/qc6" rel="nofollow noreferrer">Fast case, same indexes as above.</a></li> </ol> <p>Thanks very much for your help! Any pointers will be really appreciated!</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USJuan Carlos Coto
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POErratic indexed query performance in PostgreSQL
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POErratic indexed query performance in PostgreSQL
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POErratic indexed query performance in PostgreSQL
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhat is the size of the indexes? And the size of the dataset?
      singulars
      1. POErratic indexed query performance in PostgreSQL
      1. USGothmog
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload