Hot answers tagged


A LEFT JOIN can solve it, like Laurenz provided. But I suggest an ARRAY constructor in a LATERAL subquery instead: SELECT, b.book_list FROM library l CROSS JOIN LATERAL ( SELECT ARRAY( SELECT title FROM books WHERE library = ) ) b(book_list) WHERE = :library_no; This way, you don't need to aggregate in ...


You need a left join: ... FROM library LEFT JOIN books ON = books.library Then you will also get libraries with no books.


The values for id 5 and LIMIT must be calculate beforehand and passed on to the query, because LIMIT must have fixed values or you have to use a prepared statement CREATE TABLE table1 (`id` int, `level` int, `score` int, `timestamp` varchar(19)) ; INSERT INTO table1 (`id`, `level`, `score`, `timestamp`) VALUES (4, 1, 70, '2021-01-14 21:50:...


In general you should include the scripts that generate your Table schemas and populates them with data. (Also for performance questions, you should include the execution plan too.) I couldn't do a lot of testing without real data, but I believe this query should improve the performance you're seeing: DECLARE @my DATE = '2019-12-01' DECLARE @nextMonthYear ...


The planner doesn't understand how the restriction on s.subscription_id interacts with the merge join. The index scan on "s" gets to quickly skip about half the tuples by jumping to the middle of the index, while the index scan on "si" then will read through all the tuples that correspond to the quickly-skipped ones from table "s&...


You need to group by the submission_id: like: SELECT submission_id sub_id, GROUP_CONCAT(DISTINCT c1.option_name)datimkt FROM form_results d JOIN field_options c1 ON FIND_IN_SET(c1.option_value, d.datimkt) GROUP BY sub_id;

Only top voted, non community-wiki answers of a minimum length are eligible