Hi ,
Thanks for the information. But the PARGMA is not working. Its giving parse
exception as seen below. I tried different combination of this statement
but none of it worked.
0: jdbc:ignite:thin://127.0.0.1/> PRAGMA PUBLIC.table_info(SUPPLIER);
Error: Failed to parse query. Syntax error in SQL
Hi,
There is the ticket [1] for the issue.
While the ticket is not resolved try to use PRAGMA table_info(table-name); as
explained in the SQLite PRAGMA documentation [2].
[1] https://issues.apache.org/jira/browse/IGNITE-16667
[2] http://www.sqlite.org/pragma.html#pragma_table_info
пн, 30 мая
Hi ,
I have created a table in ignite using SQLLine and I want to see which
columns in that table are the primary key. When i queried
*SYS.TABLE_COLUMNS* I don't see the Primary key columns.Can someone please
help me how can i get the primary key columns of already created ignite
table? Following
Hi Alex,
> I'm not going to write any new records or update existing ones for such
> tables through Ignite. So I can skip the overrides in CacheStore
> implementation, right? (I'm using default implementation at the moment)
That's right.
https://apacheignite.readme.io/docs/id-generator
> Thi
Hi Denis,
thanks for your reply
>>How will you access such records in Ignite? SQL lookups?
Yes, using SQL lookups
>>The default CacheStore implementation that writes down changes to a
relational database needs to be overridden.
I'm not going to write any new records or update existing ones for
to update those Postgres tables with Ignite
data.
-
Denis
On Tue, Jul 21, 2020 at 12:27 PM Alex Panchenko
wrote:
> Hi,
>
> I have an Ignite cluster with 3rd party persistence enabled (Postgres db).
> I
> have a few tables in Postgres which don't have primary keys bur I
Hi,
I have an Ignite cluster with 3rd party persistence enabled (Postgres db). I
have a few tables in Postgres which don't have primary keys bur I need to
keep these tables in Ignite:
They look like this table (as an example):
KeyValuesTable {
key: UUID
value: String
}
NOTE
cheev
>>
>>
>> чт, 18 июн. 2020 г. в 16:11, narges saleh :
>>
>>> Thanks Ilya.
>>> Now I can see the complete plan, and it shows scanning the large tables
>>> (but not the others). Increasing index size didn't help.
>>> I only have primar
ery plans.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 18 июн. 2020 г. в 16:11, narges saleh :
>
>> Thanks Ilya.
>> Now I can see the complete plan, and it shows scanning the large tables
>> (but not the others). Increasing index size didn't help.
>> I only have
> I only have primary keys on the caches and the fields in the primary keys
> are the ones used in my where clause, so I am not sure
> what's going on.
> Currently, I am testing on one node only, so all the data should be in one
> place.
>
>
> On Thu, Jun 18, 2020 at
Thanks Ilya.
Now I can see the complete plan, and it shows scanning the large tables
(but not the others). Increasing index size didn't help.
I only have primary keys on the caches and the fields in the primary keys
are the ones used in my where clause, so I am not sure
what's going on.
Currently
versions may not be able to search by its
fields.
Regards,
--
Ilya Kasnacheev
чт, 18 июн. 2020 г. в 13:13, narges saleh :
> Hi All,
>
> Shouldn't primary keys result in indexes and if so, shouldn't I be able to
> see them when I list indexes?
> Does inline index size applicable to p
Hi All,
Shouldn't primary keys result in indexes and if so, shouldn't I be able to
see them when I list indexes?
Does inline index size applicable to primary keys too?
Additionally, when I do explain plan on a query which involves tables with
primary keys, shouldn't I see the primary key/index
13 matches
Mail list logo
