I am receiving a "wildcard query expansion resulted in too many terms" error when executing a query similar to the following:
SELECT *
FROM table_a
WHERE contains(clob_field, '%a%') > 0;
Does anyone know a workaround/solution to this problem?
According to this, you may need to increase the wildcard_maxterms parameter, or take further steps. See the link for details (I'm not an expert in Oracle Text though).
Related
I am running into an issue where if I have more than 15 LIKE operators within a case statement, I get an error java.lang.StackOverflowError.
Here is an example of what I am doing against a table with 60 million rows:
SELECT
CASE WHEN field LIKE '%value%' THEN 'result'
WHEN field LIKE '%value2%' THEN 'result2'
.... 14 more of those
END
I haven't seen this limitation documented anywhere. Any ideas how to get around this?
It sounds like it's an out-of-memory error.
I think you have some options:
use an intermediate table before doing the like processing (or use intermediate tables to process subsets of your initial data)
bump up the number of queue slots that you're using for this query to have more memory available https://docs.aws.amazon.com/redshift/latest/dg/r_wlm_query_slot_count.html
take a look at the explain output to see if it gives you clues about what's going wrong
You could Create a Scalar Python User-Defined Function to replace the LIKE comparisons.
Then, just use:
SELECT f_myfunc(field)
This turned out to be a driver issue. I was initially using 1.2.16.1027 and upgraded to 1.2.20.1043 and I am no longer receiving the error.
Note that PostgreSQL website mentions that it has a limit on number of columns between 250-1600 columns depending on column types.
Scenario:
Say I have data in 17 tables each table having around 100 columns. All are joinable through primary keys. Would it be okay if I select all these columns in a single select statement? The query would be pretty complex but can be programmatically generated. The reason for doing this is to get denormalised data to populate a web page. Please do not ask why though :)
Quite obviously if I do create table table1 as (<the complex select statement>), I will be hitting the limit mentioned in the website. But do simple queries also face the same restriction?
I could probably find this out by doing the exercise myself. In the next few days I probably will. However, if someone has an idea about this and the problems I might face by doing a single query, please share the knowledge.
I can't find definitive documentation to back this up, but I have
received the following error using JDBC on Postgresql 9.1 before.
org.postgresql.util.PSQLException: ERROR: target lists can have at most 1664 entries
As I say though, I can't find the documentation for that so it may
vary by release.
I've found the confirmation. The maximum is 1664.
This is one of the metrics that is available for confirmation in the INFORMATION_SCHEMA.SQL_SIZING table.
SELECT * FROM INFORMATION_SCHEMA.SQL_SIZING
WHERE SIZING_NAME = 'MAXIMUM COLUMNS IN SELECT';
Hello I was wondering if someone with some knowledge of Cassandra could help me. Right now i'm investigating the read path of Cassandra using a debugger but for some reason cannot find the specific place where the columns for a row are filtered with respect to the query.
I have issued both queries:
"select * from tabl where name1='rowkey8888';"
and
"select name9 from tabl where name1='rowkey999211';"
What is confusing to me is that they are both considered SliceFromReadCommand commands and the
SliceQueryFilter object associated with the command is the same for both: [reversed=false, slices=[[, ]], count=10000, toGroup = 0]
My question is that can anyone explain to me the reason for this behaviour, as I was under the impression when a column name was given in the query (name9 in the above case) then
the command would be a SliceByNamesReadCommand and the specified columns would be in the QueryFilter slices array. Additionally would anyone be able to point out where this filtering is done as I cannot find it?
For reasons related to TTL handling, C* actually has to query a "slice" of the partition even when you give it a specific name.
CollationController is a good place to start code diving.
Why can't one use an output column in the having clause in postgresql? It doesn't change expressivity of the language anyhow, just forces people to rewrite output column definition in having clause. Is a way to avoid that, apart from putting the whole query as a subquery in SELECT * FROM (...) AS t WHERE condition ?
Bacause it's not implemented? And if you're asking why it wasn't implemented, I see 2 possible explanations:
standard doesn't require it
nobody had time to spent on it
if you'd like to have it - mail to -hackers, talk about, and then implement.
Frankly I don't see it as a big problem - it's not like you have 1000 characters to retype.
If you've got a very complicated SELECT statement and some records aren't included because of a join, what is the easiest way to debug this and find the reasons why?
Change the JOINS / INNER JOINS to OUTER JOINS and look for NULLs where they shouldn't be.
You could include your ON logic in the WHERE clause, phrase it like this:
WHERE 1=1
AND...
AND...
and just comment out as many of the terms until you isolate the unexpected behaviour.
I don't know if this will help you, but when I find myself with a complex Select that I'm having a hard time maintaining, or debugging, I'll break it up into separate common table expressions (CTE's). I've found this makes many of my queries much easier to understand and maintain.
Binary Search stylee:
If you have 10 joins, comment out the last 5.
Still have the problem? comment out the last 2/3 joins that are still uncommented
Still have the problem? comment out the last 1/2 joins that are still uncommented
Do this until you get down to it working, then the problem will lie in the last joins you commented out.
Yes you could do them one at a time but this is usually quicker.
Obviously you will have to comment out all the columns not used in the select statement, but I normally just put /* */ around all the columns, then put a * instead.
Just look at the number of results returned.