What if the greatest magic came with one impossible rule?

Marina has finally found happiness on land with Prince Leo.

But there is one secret she can never reveal…

She is a mermaid.

When Marina discovers a magical silver shell that allows her to remain human while still hearing the voices of the sea, it seems like every dream has come true.

Until the Sea Witch opens her ancient rulebook…

Never reveal to anyone that you are a mermaid.

Break the rule…

and an ancient curse sleeping beneath the ocean will awaken.

As Marina struggles to protect both her secret and the people she loves, she must make impossible choices between friendship, honesty, sacrifice, and destiny.

Can love survive when the truth is too dangerous to tell?

Or will the Sea’s Curse change everything forever?

✨ Inside this beautifully illustrated story, children will discover:

• 🐚 An exciting fantasy adventure
• 💙 Lessons about honesty and responsibility
• 🌊 Courage in the face of difficult choices
• 👑 Friendship, kindness, and true love
• 📖 Full-color illustrations on every page

Perfect for children ages 4–8, bedtime reading, classroom story time, and young readers who love magical adventures, mermaids, and fairy tales.

Continue the magical journey in The Whispering Sea Chronicles with Book 3: The Sea’s Curse!

Buy the book on Amazon

Buy the book on Amazon

Buy the book on Amazon

Đây

Mình sẽ kể cho bạn nghe, 1 câu chuyện về tình yêu

À, không phải là chuyện yêu đương nam nữ đâu nhé, thế giới này vốn đã ngập trong những câu chuyện như vậy rồi.

Mà là tình yêu của gia đình chúng tôi dành cho Milu, tên của 1 con chó.

***

Lần đầu tôi gặp Milu là khi tôi đi mua quà cho  1 cô gái mà tôi mới quen (vợ tôi bây giờ)

Bữa đấy, tôi tới 1 cửa hàng bán chó khá nổi tiếng ở quê. Và nhanh chóng bị choáng ngợp bởi rất nhiều các loại chó. Chó đốm, chó mặt xệ, chó becge, trai có gái có, mập có ốm có, 1 2 tháng tuổi đếm 1 năm 2 năm tuổi . Đủ sắc màu, thể loại, hình hài, khuôn mặt cứ như chuyện  101 chú chó đốm của Smith.

Tôi nói thật to ” nhà tao con nghèo, nhưng chó nào muốn ở với gia đình tao, có gì ăn nấy, sướng cùng sướng, có khổ cùng khổ, tao sẽ chăm sóc suốt đời, thì sủa lên 3 tiếng gâu gâu gâu”

Bỗng nhiên tôi nghe 3 tiếng gâu gâu gâu từ giữa bầy chó đáp lại

Nhìn thật kỹ, đó là 1 con poodle nhỏ nhắn, màu nâu vàng, đang quẫy đuôi lanh lợi và tinh quái vừa nhìn tôi vừa lắc lắc cái mông ra chiều vui vẻ.

Tôi lại hỏi: chắc chưa, nhà nghèo đấy, có chịu được không?

Chú chó này lại tiếp tục nhìn tôi, quẫy quẫy cái đuôi, sủa thành tiếng, vẻ mặt rất trông chờ và vui vẻ, như đã chờ đợi tôi từ rất lâu

Như duyên trời định, tôi không suy nghĩ nữa, liền mua ẻm chó này mang về.

Và đấy là lần đầu tiên tôi gặp và chọn mua milu thông minh, lanh lợi, xinh đẹp nhà tôi.

***

Câu chuyện bên trên là tôi hay kể đùa vợ tôi thôi, chứ không có thật đâu các bạn nhé.

Nhưng, bạn biết đấy, giữa hằng hà sa số những sinh mệnh, gặp được nhau đã là 1 cái duyên trời định. Tôi đoán milu và gia đình tôi cũng thế.

***

Sau khi mua Milu về, tôi lên lịch hẹn đi ăn tối với cô bạn mới của tôi.

Tối đến. Tôi giấu nhẹm Milu vào bụi cây gần Gozo, quán cafe nơi chúng tôi gặp nhau
(Ẻm cứ sủa không ngừng)

Tôi ngồi với bạn gái mình 1 lát thì giả vờ vô tình hỏi bạn tôi “hình như có tiếng chó sủa ở đâu ấy em ạ, em có nghe không?”

“Em cũng nghe thế” cô ấy trả lời

Thế là tôi đi 1 vòng quanh quán ra vẻ tìm kiếm. Sau 1 hồi khổ sở đi tìm nguồn gốc của tiếng chó sủa, cuối cùng tôi cũng tìm ra 1 con chó đang vừa quẫy đuôi vừa sủa trong bụi cây

“A, có con chó nằm trong bụi nè em ah, hình như bị ai đó bỏ rơi” tôi reo lên mừng rỡ.

Rồi ẵm nó ra, “nhìn tội quá, em cho nó ăn đi”

Cô ấy vuốt ve milu, xoa xoa, ôm vào lòng, ra chiều thích thú lắm .

“Anh thấy nó bị bỏ rơi rồi ấy, hay là mình đem nó về nuôi đi em”

Em ấy gật đầu.

Tối đó, tôi chở bạn gái tôi về nhà, cô ấy ngồi sau vừa ôm vừa vuốt ve Milu

Chúng tôi cùng ngân nga hát trên đường về

Phú Yên, trời tối, sương đêm lạnh, 3 tâm hồn đang dựa vào nhau ấm áp.

***

Đấy, chuyện nhà tôi nó nhẹ nhàng, giản dị thế đấy các bạn

À, mà đó là khởi đầu thôi nhé, tôi sẽ kể tiếp câu chuyện về Milu và gia đình chúng tôi khi có thời gian, bạn cùng đón chờ nhé.

Tiếp theo : 

Phần 2: xáo trộn và cơ hội.

Phần 3: lên rừng xuống biển, những chuyến hành trình ra bắc vào nam

Phần 4: 2 lần đập cửa bác sĩ cấp cứu lúc nửa đêm

Phần 5: 7 thiếu nhi, những thành viên Milu mới của gia đình.

Phần 6: Mận

===

Here,
I want to tell you a story about love.
No, it’s not a romantic love story; this world is already full of those.
It’s about the love our family has for Milu, the name of a dog.

The first time I met Milu was when I was buying a gift for a girl I had just met (now my wife).
That day, I went to a well-known dog store in my hometown and was quickly overwhelmed by the many types of dogs. Dalmatians, bulldogs, poodles, males and females, fat and thin, ranging from 1 or 2 months old to 1 or 2 years old. Every color, type, and shape—like something out of “101 Dalmatians.”
I shouted, “My family is poor, but any dog that wants to live with us will get what we have to eat, will share in our joys and sorrows, and I will take care of it for life. So bark three times: woof woof woof!”
Suddenly, I heard three barks, “woof woof woof,” from the middle of the pack.
It was a small, brown-and-tan poodle, wagging its tail playfully and looking at me with a happy, wiggling bottom.
I asked again, “Are you sure? We’re poor. Can you handle it?”
The dog continued to look at me and barked with an eager and joyful expression.

As if destined by fate, I bought this little dog.
And that was the first time I met and chose my smart, lively, and beautiful Milu.

Oh, the story above is just a joke I tell my wife; it’s not true.
But you know, among countless lives, meeting each other is already a destined fate. I guess Milu and my family are the same.

After bringing Milu home, I scheduled a dinner with my new girlfriend.

That evening, I hid Milu in the bushes near the café where we were meeting
(She kept barking).

While I was sitting with my girlfriend, I pretended to casually ask, “I think I hear a dog barking somewhere. Do you hear it?”
“Yes, I hear it too,” she replied.
So I went around the café searching. After struggling to find the source of the barking, I finally found the dog wagging its tail and barking in the bushes.
“Oh, there’s a dog in the bushes. It seems to have been abandoned,” I exclaimed with delight.
I picked it up and said, “It looks so pitiful. Let’s feed it.”
She petted Milu, stroked her, and hugged her, clearly pleased.
“I think it was abandoned. Maybe we should take it home with us,” I suggested.
She nodded in agreement.

That night, I took my girlfriend home, and she sat in the back, hugging and petting Milu.
We sang on the way home.
Phu Yen, the night was dark, the night mist was cold, and three souls were nestled together warmly.

So that’s how simply it happened in my family.
Oh, and that’s just the beginning. I’ll continue the story about Milu and our family when I have more time. Stay tuned.

Next Story
Part 2: Disruptions and Opportunities.
Part 3: Journeys from North to South.
Part 4: Two Emergency moment and knock Doctor ‘a door at Midnight.
Part 5: Seven Children, Milu’s New Family Members.
Part 6: Our Man.

REF

https://akfpartners.com/growth-blog/scale-cube

What is subquery in PostgreSQL?

In PostgreSQL, a subquery is a query that is nested inside another query. The subquery is executed first, and its results are used as input to the outer query. Subqueries can be used in various contexts, such as in the SELECT, WHERE, and HAVING clauses of a query.

For example, consider the following query that uses a subquery to find the total number of orders for each customer:

SELECT customer_id, COUNT(*) as num_orders
FROM orders
WHERE customer_id IN (
  SELECT id
  FROM customers
  WHERE country = 'USA'
)
GROUP BY customer_id;

In this query, the subquery `(SELECT id FROM customers WHERE country = ‘USA’)` is executed first to retrieve the IDs of all customers in the USA. The outer query then uses these IDs to count the number of orders for each customer.

A common alternative to using subqueries is to use Common Table Expressions (CTEs). A CTE is a named subquery that can be referenced multiple times within a single query. The primary benefit of using a CTE is that it can make a query easier to read and understand by breaking it down into smaller, more manageable parts.

For example, the previous query could be rewritten using a CTE like this:

WITH usa_customers AS (
  SELECT id
  FROM customers
  WHERE country = 'USA'
)
SELECT customer_id, COUNT(*) as num_orders
FROM orders
WHERE customer_id IN (
  SELECT id FROM usa_customers
)
GROUP BY customer_id;

In this query, the subquery `(SELECT id FROM customers WHERE country = ‘USA’)` has been replaced with a CTE called `usa_customers`. The CTE is defined using a `WITH` statement, and it can be referenced multiple times within the same query. The outer query then uses the CTE to count the number of orders for each customer in the USA.

Both subqueries and CTEs are powerful tools in PostgreSQL that can be used to create complex queries that retrieve and manipulate data in a variety of ways.

What is CTE in PostgreSQL?

A CTE is a named temporary result set that you can reference within a SELECT, INSERT, UPDATE, or DELETE statement. It allows you to break down complex queries into smaller, more manageable parts, making the query more readable and easier to understand.

Here is an example of a CTE that computes the average price of all products:

WITH product_avg_price AS (
  SELECT AVG(price) AS avg_price FROM products
)
SELECT * FROM product_avg_price;

In this example, the CTE is named “product_avg_price” and contains a single SELECT statement that computes the average price of all products. The main SELECT statement then references the CTE and returns the result.

Common Table Expressions (CTEs) have several advantages over subqueries

1. Readability: CTEs can make a query easier to read and understand by breaking it down into smaller, more manageable parts. This can be especially useful for complex queries that involve multiple subqueries.

2. Reusability: A CTE can be referenced multiple times within a single query, which can reduce the amount of redundant code and improve query performance.

3. Recursivity: CTEs can be used to create recursive queries, which allow you to traverse hierarchical or graph-like structures, such as a tree or a social network.

4. Performance: In some cases, using a CTE can be more efficient than using a subquery. This is because a CTE is executed only once, and its results are cached in memory, whereas a subquery is executed every time it is referenced in the outer query.

5. Debugging: CTEs can be a useful tool for debugging complex queries. By breaking a query down into smaller parts using CTEs, you can more easily identify and isolate errors or performance issues.

REF

PostgreSQL CTE

Some rule and todo list to Optimize SQL

REF
https://www.pgmustard.com/blog/indexing-best-practices-postgresql

What is Compound indexes in PostgreSQL?

A compound index (also known as a composite index or a multi-column index) refers to an index that is created on two or more columns of a table. It allows PostgreSQL to quickly find rows that match a query condition based on the values in multiple columns, which can be useful for queries that involve multiple conditions that are frequently used together.

In PostgreSQL, a compound index is an index that contains multiple columns. It allows you to index on more than one column at a time and can be helpful in improving the performance of certain queries.

To create a compound index in PostgreSQL, you can use the CREATE INDEX statement and specify the columns you want to index in the index definition.

Here is an example of creating a compound index on two columns in a table:

CREATE INDEX idx_compound ON my_table (column1, column2);

This creates an index named “idx_compound” on the “my_table” table, which indexes both “column1” and “column2”.

When using a compound index, the order of the columns can be important. PostgreSQL uses the leftmost column in the index for sorting and filtering operations. For example, if you have a compound index on columns (A, B, C), the index can be used to satisfy queries that filter on A alone or on both A and B, but it cannot be used for queries that only filter on B or C.

Indexing algorithm for Compound indexes in PostgreSQL

In PostgreSQL, there are several indexing methods available for creating compound indexes, including:

– B-tree (the default indexing method)
– Hash
– GiST (Generalized Search Tree)
– SP-GiST (Space-Partitioned Generalized Search Tree)
– GIN (Generalized Inverted Index)
– BRIN (Block Range INdex)

Each indexing method uses a different algorithm for combining the values of multiple columns into a single index entry.

The B-tree indexing method, which is the most commonly used indexing method in PostgreSQL, works by concatenating the values of the indexed columns into a single string, and then storing this string as the index key. The index is then organized as a balanced tree structure, with each node containing a range of keys that fall between the keys of its parent node.

For example, if you have a compound index on columns (A, B, C), the B-tree indexing method would concatenate the values of A, B, and C into a single string for each row in the table, and then store these strings in the index in sorted order. When you query the index, PostgreSQL can use the index to efficiently search for rows that match a given set of values for A, B, and/or C.

Other indexing methods, such as GiST and GIN, use more complex algorithms for combining the values of multiple columns into a single index entry. These indexing methods are generally used for more specialized data types, such as geometric data or full-text search data.

Compound indexes optimize use case story

For example, here is the case when we need to get orders from a customer and between a time range

SQL query

 
SELECT *
FROM orders
WHERE customer_id = 123
AND order_date BETWEEN '2022-01-01' AND '2022-12-31'

We will analyze how that query could benefit from a compound index:

Assuming that the `orders` table has millions of rows, a single index on either `customer_id` or `order_date` may not be sufficient to provide efficient query performance. However, creating a compound index on both columns can significantly speed up this query.

To create a compound index on `customer_id` and `order_date`, you can use the following SQL command:

CREATE INDEX idx_orders_customer_date ON orders (customer_id, order_date);

When PostgreSQL processes the query, it can use the compound index to quickly identify the subset of rows that match both criteria, rather than having to scan the entire table. The compound index can be used because it can satisfy both the `customer_id = 123` and `order_date BETWEEN ‘2022-01-01’ AND ‘2022-12-31’` conditions with a single index lookup.

What if we use single index for the above case ?

For the SQL query I provided for the case above:

SELECT *
FROM orders
WHERE customer_id = 123
AND order_date BETWEEN '2022-01-01' AND '2022-12-31'

We can still use a single index to improve query performance.

If you have to choose one of the two columns to create an index on, it’s generally better to choose the column with higher selectivity, which is the one that has more unique values. In this case, assuming that `customer_id` has higher selectivity than `order_date`, you can create an index on `customer_id` like this:

CREATE INDEX idx_orders_customer ON orders (customer_id);

This index will allow PostgreSQL to quickly find all the rows with `customer_id = 123`, and then filter those rows further by the `order_date BETWEEN ‘2022-01-01’ AND ‘2022-12-31’` condition using a sequential scan.

Note that this approach may not be as efficient as a compound index, as it may require scanning a larger number of rows to find those that meet the `order_date` condition. However, it can still be a significant improvement over not having an index at all.

So, it’s always a good idea to evaluate the selectivity of the columns involved in the query, and create indexes on the ones that have the highest selectivity. If you have more than one column with high selectivity, you may consider creating a compound index that includes all those columns.

What if we use two single indexes for the above case ?

Using two single indexes can still improve query performance, but it may not be as efficient as a compound index in this case.

You can create two separate single-column indexes on `customer_id` and `order_date` like this:

CREATE INDEX idx_orders_customer ON orders (customer_id);
CREATE INDEX idx_orders_date ON orders (order_date);

PostgreSQL can use each of these indexes to identify the subset of rows that match either `customer_id = 123` or `order_date BETWEEN ‘2022-01-01’ AND ‘2022-12-31’`. However, PostgreSQL will need to perform a separate index scan for each index, and then combine the results using an additional operation, which can be less efficient than a single compound index.

To ensure that PostgreSQL uses both indexes, you can use the `ENABLE_SEQSCAN` option to disable sequential scans:

SET enable_seqscan = off;

SELECT *
FROM orders
WHERE customer_id = 123
AND order_date BETWEEN '2022-01-01' AND '2022-12-31';

SET enable_seqscan = on;

This will force PostgreSQL to use only the indexes to find the matching rows, and not use sequential scans. However, this approach may still be slower than using a compound index because it requires two separate index scans and additional processing to combine the results.

So, using multiple single-column indexes can be a good strategy when you have different queries that involve different combinations of columns, and you want to optimize each query separately. However, for queries that involve multiple conditions that are frequently used together, a compound index can provide more efficient query performance.

Cost of Compound index in PostgreSQL

The cost of a compound index in PostgreSQL depends on several factors, including the size of the table, the number of columns included in the index, and the selectivity of each column.

When PostgreSQL evaluates a query that involves a compound index, it uses statistics about the distribution of data in the index to estimate the cost of various query plans. The estimated cost takes into account factors such as the number of disk I/O operations required to read the index, the number of rows that need to be filtered based on the index conditions, and the estimated cost of any additional processing required to complete the query.

The cost of a compound index can be influenced by the order of the columns in the index definition. When defining a compound index, it’s generally recommended to list the most selective column first, followed by the second most selective column, and so on. This can help PostgreSQL to more efficiently filter the index based on the most selective conditions first, before filtering further based on less selective conditions.

Overall, the cost of a compound index can be relatively high compared to a single-column index, especially if the table is large and the index includes multiple columns with low selectivity. However, in many cases, the performance benefits of a compound index can outweigh the cost, especially for queries that frequently involve multiple conditions that are frequently used together.

More info: how to optimize Compound indexes in PostgreSQL

To optimize the compound index, you may want to consider the order of the indexed columns. In general, you should order the columns in the index based on their selectivity and the order of the search conditions in the query. In this example, `customer_id` has higher selectivity than `order_date`, so it should be listed first in the index.

You may also want to consider the size of the indexed columns and the overall size of the index. In general, you should avoid creating excessively large indexes, as they can slow down insert, update, and delete operations on the table.

To further optimize the query performance, you may want to consider other indexing methods, such as GiST or BRIN, depending on the specific characteristics of the data being indexed. Additionally, you may want to consider optimizing the query itself, such as by using a covering index or by rewriting the query to use a more efficient join strategy.

Creating a compound index on multiple columns can significantly improve the performance of SQL queries that involve multiple search criteria, but it’s important to carefully consider the characteristics of the data and the specific query patterns before creating indexes.

So, compound indexes in PostgreSQL can be a useful tool for optimizing the performance of queries that filter or sort on multiple columns. When creating a compound index, it’s important to consider the order of the columns in the index to ensure optimal performance.

Several things to consider to ensure that it provides the best performance benefits when using a compound index in PostgreSQL:

1. Selectivity of columns: It’s important to consider the selectivity of the columns included in the index. Selectivity refers to the number of distinct values in a column relative to the total number of rows in the table. Columns with high selectivity are more useful for indexing, as they can help to quickly filter the index to a small subset of rows.

2. Column order: The order in which the columns are listed in the compound index definition can have an impact on query performance. It’s generally recommended to list the most selective columns first, followed by less selective columns.

3. Data distribution: The distribution of data in the table can also affect the performance of a compound index. If the values in the indexed columns are highly skewed or have many null values, the index may be less effective at filtering rows.

4. Index size: Compound indexes can be larger in size than single-column indexes, as they store data for multiple columns. This can increase the disk space required to store the index and may affect the speed of index scans.

5. Maintenance overhead: Compound indexes require additional maintenance overhead compared to single-column indexes. Whenever the underlying table is updated, the index must be updated as well.

By considering these factors and designing the compound index carefully, it’s possible to create an index that provides the best performance benefits for a given set of queries. However, it’s important to note that the optimal index design can vary depending on the specific use case and the distribution of data in the table, so it’s important to carefully evaluate the effectiveness of any index design through benchmarking and testing.

REF
https://www.pgmustard.com/blog/indexing-best-practices-postgresql