Consider applying "database normalization" to the schema so that the columns
are only in one table, and then pass around synthetic keys.
On 6/5/23 10:06, Lorusso Domenico wrote:
Thank's, you are right, I've the same doubts.
A composite type is useful because I've to add all these information on
On 6/5/23 11:19 AM, Lorusso Domenico wrote:
thank's Adrian, my problem is I've to use CloudSql, so I can't install
extensions not verified by google...
It is not actually an extension, it is PERL program. Though I'm guessing
that will still be an issue.
--
Adrian Klaver
adrian.kla...@aklaver
thank's Adrian, my problem is I've to use CloudSql, so I can't install
extensions not verified by google...
Il giorno lun 5 giu 2023 alle ore 17:17 Adrian Klaver <
adrian.kla...@aklaver.com> ha scritto:
> On 6/5/23 08:06, Lorusso Domenico wrote:
> > Thank's, you are right, I've the same doubts.
>
On Mon, Jun 5, 2023 at 12:08 PM Laurenz Albe
wrote:
> On Mon, 2023-06-05 at 17:06 +0200, Lorusso Domenico wrote:
> > A composite type is useful because I've to add all these information on
> many tables and because
> > it more easy to pass all these informations to functions that have to
> ensure
On Mon, 2023-06-05 at 17:06 +0200, Lorusso Domenico wrote:
> A composite type is useful because I've to add all these information on many
> tables and because
> it more easy to pass all these informations to functions that have to ensure
> the right format and evaluation.
>
> Talking about first
On 6/5/23 08:06, Lorusso Domenico wrote:
Thank's, you are right, I've the same doubts.
A composite type is useful because I've to add all these information on
many tables and because it more easy to pass all these informations to
functions that have to ensure the right format and evaluation.
Thank's, you are right, I've the same doubts.
A composite type is useful because I've to add all these information on
many tables and because it more easy to pass all these informations to
functions that have to ensure the right format and evaluation.
Talking about first point I could use the "tab
Thank's a lot, I'll take care of it.
Il giorno lun 5 giu 2023 alle ore 16:18 Ron ha
scritto:
> On 6/5/23 09:02, Laurenz Albe wrote:
> > On Mon, 2023-06-05 at 11:49 +0200, Lorusso Domenico wrote:
> >> I've a couple of questions about composite type.
> >> Suppose this composite type:
> >> CREATE T
try this (there is some comment)
with t_res as (
select RSNO, KNO
from TBL_RES
where TBL_RES.CID >= to_date('2022/07/01', '/MM/DD')
and TBL_RES.CID <= to_date('2022/07/31', '/MM/DD')
and TBL_RES.COD >= to_date('2022/07/01', '/MM/DD')
and TBL_RES.COD <= to_date('2022/07/31', '/MM/D
On 6/5/23 09:02, Laurenz Albe wrote:
On Mon, 2023-06-05 at 11:49 +0200, Lorusso Domenico wrote:
I've a couple of questions about composite type.
Suppose this composite type:
CREATE TYPE my_type AS (
user_ts_start My_start_timestamp,
user_ts_end My_end_timestamp,
db_ts_start My_sta
On Mon, 2023-06-05 at 11:49 +0200, Lorusso Domenico wrote:
> I've a couple of questions about composite type.
> Suppose this composite type:
> CREATE TYPE my_type AS (
> user_ts_start My_start_timestamp,
> user_ts_end My_end_timestamp,
> db_ts_start My_start_timestamp,
> db_ts_end M
Thank you very much for taking the time to reply to my question.
I followed your suggestion and rewrote the SQL using Common Table Expression
(CTE).
Unfortunately, there was no significant improvement in performance.
At 2023-06-05 17:47:25, "Lorusso Domenico" wrote:
Hello,
In many cas
Hello guys,
I've a couple of questions about composite type.
Suppose this composite type:
CREATE TYPE my_type AS (
user_ts_start My_start_timestamp,
user_ts_end My_end_timestamp,
db_ts_start My_start_timestamp,
db_ts_end My_end_timestamp,
audit_record jsonb
);
My_start_timestamp
Hello,
In many case a formal writing and usage of with statement could solve the
issue.
If you need join, use always join:
where T_POV2.RSNO = T_CUST.RSNO
and T_POV2.KNO = T_CUST.KNO
and T_POV2.GSTSEQ = T_CUST.GSTSEQ)
this is an inner join.
I mean something like this
with t_pov2 as (
select T_CUST
Hi, David
>The above join's selectivity estimation seems to be causing an upper
>join to resort to performing a Nested Loop join because the planner
>thinks the join will only produce 1 row.
>
>Unfortunately, extended statistics only help for base relation
>estimations and do nothing for j
On Mon, 5 Jun 2023 at 18:56, gzh wrote:
> I'm running into some performance issues with my SQL query.
> The following SQL query is taking a long time to execute.
> -> Hash Join (cost=253388.44..394112.07 rows=1 width=56) (actual
> time=1197.484..2954.084 rows=330111 loops=1)
>
Indices on TBL_RES.CID, TBL_RES.COD and the "join columns"?
Have you vacuumed and analyzed the tables lately?
Oliver's comment about first optimizing the individual subselects is also SOP.
On 6/5/23 01:56, gzh wrote:
Hi everyone,
I'm running into some performance issues with my SQL query.
The
On Mon, 5 Jun 2023 at 07:56, gzh wrote:
> Hi everyone,
> I'm running into some performance issues with my SQL query.
> The following SQL query is taking a long time to execute.
>
> Execution Plan：
> explain analyse
> select * from TBL_RES
> left outer join(select T_CUST.RSNO RSNO2 ,
> T_CUST.KNO
On Mon, 2023-06-05 at 10:18 +0800, Wen Yi wrote:
> when I study the tcp connection, I found that if the server active close the
> connection,
> the server will send a fin package to the client and the client will reply a
> ack package.
> As this:
>
> Server >(FIN) Client
> Server <(ACK)
19 matches
Mail list logo
