I actually come with a question/problem. I implemented QuestDB for a customer to monitor Airflow via statsd/Telegraf + Grafana. It is all running smoothly, and there are no problems regarding the performance. However, on the side of browseability, I have no way to see, what tables I have in the database. tables() is empty, the browser does not display anything either, but the tables created by the influx line protocol do exist and have data Version: 6.5.4 Set up via the official Docker Image If there is more info required I am happy to provide.

Hi JM . Could you share qdb logs ? Have you tried running :

select * from all_tables();

?

Hey JM, we do not fully support DBeaver as of now, we would thus not recommend it for the time being

Thank you for the answers! Both

select * from tables();

and

select * from all_tables();

return the columns, but no rows. As for the logs, I have yet to find them. What would be the default location (I have not modified the log.conf). I only mapped the questdb home folder between the system and the container. I cannot guarantee that I can share the logs, since it may contain data I am not allowed to share. Unfortunate that DBeaver is not supported (yet) but I will have to deal with it. Is there a recommended tool aside from the browser interface?

I think you can start with docker logs command . You don't need to share everything - just the piece at the time you're running those queries .

Okay, I just executed it again and got the log from the command alone.

2022-11-29T11:01:29.379524Z I http-server connected [ip=<removed>, fd=1587]
2022-11-29T11:01:29.380892Z I i.q.c.h.p.JsonQueryProcessorState [1587] exec [q='select * from all_tables()']
2022-11-29T11:01:29.380907Z I i.q.c.h.p.QueryCache hit [thread=questdb-shared-2, sql=select * from all_tables()]
2022-11-29T11:01:29.380915Z I i.q.c.h.p.JsonQueryProcessorState [1587] execute-cached [skip: 0, stop: 1000]
2022-11-29T11:01:29.381100Z I i.q.c.h.p.JsonQueryProcessorState [1587] timings [compiler: 0, count: 0, execute: 214916, q=`select * from all_tables()`]
2022-11-29T11:01:29.381142Z I i.q.c.h.p.JsonQueryProcessor all sent [fd=1587, lastRequestBytesSent=388, nCompletedRequests=9, totalBytesSent=191002]
2022-11-29T11:01:29.381168Z I i.q.c.h.p.QueryCache push [thread=questdb-shared-2, sql=select * from all_tables()]

Thank you for the tips. I only started working with open source stacks fairly recently ago 🙂

It's weird that there are no errors and you can't see tables but can query them . Could you check qdb json response with browser web console ? Is it empty or is there an error ?

I am sorry but I do not see how/where to access the JSON response. Would I need some browser plugin for that or should it be integrated in the qdb interface?

No, web consoles are built into browsers. You've to open it (https://balsamiq.com/support/faqs/browserconsole/), open network tab, find request and check the content .

I did it with the cURL request now

{"query":"SELECT * FROM all_tables();","columns":[{"name":"table","type":"STRING"}],"dataset":[],"count":0}

I will also check with the developer console

Hello! I faced a similar problem when testing the questDB. In my case was the type of the SO file system format.

Ah yes. QuestDB is indeed runnign on CentOS7 on an XFS Filesystem and I found the same error message in the logs. Thanks for helping out there!

You are welcome!

Right. Thanks for mentioning this , @Antonio Jimenez Did you create a GH issue ? If there's enough demand and advantage to using XFS we might decide to test and support it . @JM For the time being it'd be better to switch to EXT4 .

Maybe the Web or QuestDB should be more clear with this kind of problems. Find this problem was a little time consuming. 😛

I will see if that is possible. I am not in charge for the system administration there but I will discuss it.

I agree that docs could be improved .

@Amy Wang FYI