So I have created a custom post type with custom values and customize my custom post type admin columns.

You can see here how my custom post type is looking in admin panel.

And as you can see I can order by title all posts and I was wondering if I could do same for all columns, like "info" etc. 

Is it possible? 

I am using this code, to display columns like I wanna :

//display catalog products in nice list
add_action("manage_posts_custom_column",  "catalog_custom_columns");
add_filter("manage_edit-catalog_columns", "catalog_edit_columns");

function catalog_edit_columns($columns){
  $columns = array(
    "cb" =&gt; "&lt;input type=\"checkbox\" /&gt;",
    "title" =&gt; "Product Title",
    "description" =&gt; "Info",
    "skills" =&gt; "Category",
     "year" =&gt; "Price",

  );

  return $columns;
}



function catalog_custom_columns($column){
  global $post;

  switch ($column) {
    case "description":
      the_content();
      break;
     case "skills":
      echo get_the_term_list($post-&gt;ID, 'atrakcijas', '', ', ','');
      break;
    case "year":
      $custom = get_post_custom();
      echo $custom["product_price"][0]; ?&gt;Ls&lt;?php
      break;

  }
}



Question: Slow queries related to subqueries using aggregation
Answer: Your approach ("aggregate first, join later") generally performs best when you need to retrieve the whole table or large parts of it - or as long as the aggregated table is small.

For only a few rows in the result, this gets disproportionately expensive for big tables, since the whole table (event_dates in your case) has to be processed. In these cases, it's better to revert the paradigm to "join first, aggregate later". The equivalent query would then be:

SELECT e.id
      ,array_agg(ed.date_start) AS starts
      ,array_agg(ed.date_end)   AS ends
      ,...
FROM   editions       e
JOIN   edition_events ee ON ee.edition_id = e.id
JOIN   events         ev ON ev.id = ee.event_id
JOIN   event_dates    ed ON ed.event_id = e.id
WHERE  e.id = ?
GROUP  BY e.id;


This should help with any version of Postgres.
Also using table aliases to simplify the syntax.

I don't see how LATERAL (Postgres 9.3+) could help this query. You would use it to reference a column from the left side of the join tree that you couldn't access on the same query level otherwise, often to produce multiple rows to join to. Neither is the case here. What you are thinking of can be implemented with plain old correlated subqueries, but those typically perform worse.
Don't take my word for it. Run a quick test with EXPLAIN ANALYZE for your case (with your real life data), then you know for sure.