Amazon Redshift tidak akan lagi mendukung pembuatan UDF Python baru mulai Patch 198. UDF Python yang ada akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Penulisan ulang kueri otomatis untuk menggunakan tampilan terwujud
<a name="materialized-view-auto-rewrite"></a>

Anda dapat menggunakan penulisan ulang kueri otomatis dari tampilan terwujud di Amazon Redshift agar kueri penulisan ulang Amazon Redshift menggunakan tampilan terwujud. Melakukan hal ini mempercepat beban kerja kueri bahkan untuk kueri yang tidak secara eksplisit mereferensikan tampilan yang terwujud. Saat Amazon Redshift menulis ulang kueri, Amazon Redshift hanya menggunakan tampilan terwujud yang mutakhir.

## Catatan penggunaan
<a name="mv_auto-rewrite_usage"></a>

Untuk memeriksa apakah penulisan ulang kueri secara otomatis digunakan untuk kueri, Anda dapat memeriksa rencana kueri atau STL\_EXPLOW. Berikut ini menunjukkan pernyataan SELECT dan output EXPLORE dari rencana query asli.

```
SELECT catgroup, SUM(qtysold) AS sold
FROM category c, event e, sales s
WHERE c.catid = e.catid AND e.eventid = s.eventid
GROUP BY 1;

EXPLAIN 
 XN HashAggregate  (cost=920021.24..920021.24 rows=1 width=35)
   ->  XN Hash Join DS_BCAST_INNER  (cost=440004.53..920021.22 rows=4 width=35)
         Hash Cond: ("outer".eventid = "inner".eventid)
         ->  XN Seq Scan on sales s  (cost=0.00..7.40 rows=740 width=6)
         ->  XN Hash  (cost=440004.52..440004.52 rows=1 width=37)
               ->  XN Hash Join DS_BCAST_INNER  (cost=0.01..440004.52 rows=1 width=37)
                     Hash Cond: ("outer".catid = "inner".catid)
                     ->  XN Seq Scan on event e  (cost=0.00..2.00 rows=200 width=6)
                     ->  XN Hash  (cost=0.01..0.01 rows=1 width=35)
                           ->  XN Seq Scan on category c  (cost=0.00..0.01 rows=1 width=35)
```

Berikut ini menunjukkan output EXPLORE setelah penulisan ulang otomatis berhasil. Output ini mencakup pemindaian pada tampilan terwujud dalam rencana kueri yang menggantikan bagian dari rencana kueri asli. 

```
* EXPLAIN 
     XN HashAggregate  (cost=11.85..12.35 rows=200 width=41)
       ->  XN Seq Scan on mv_tbl__tickets_mv__0 derived_table1  (cost=0.00..7.90 rows=790 width=41)
```

Hanya tampilan terwujud terbaru (segar) yang dipertimbangkan untuk penulisan ulang kueri secara otomatis, terlepas dari strategi penyegaran, seperti otomatis, terjadwal, atau manual. Oleh karena itu, kueri asli mengembalikan hasil terbaru. Saat tampilan terwujud direferensikan secara eksplisit dalam kueri, Amazon Redshift mengakses data yang saat ini disimpan dalam tampilan terwujud. Data ini mungkin tidak mencerminkan perubahan terbaru dari tabel dasar tampilan terwujud.

Anda dapat menggunakan penulisan ulang kueri otomatis dari tampilan terwujud yang dibuat pada klaster versi 1.0.20949 atau yang lebih baru.

Anda dapat menghentikan penulisan ulang kueri otomatis pada tingkat sesi dengan menggunakan SET mv\_enable\_aqmv\_for\_session ke FALSE.

## Cara kerja penulisan ulang kueri otomatis dari tampilan terwujud
<a name="mv_auto-rewrite_behavior"></a>

Berdasarkan pengoptimalan internal, Amazon Redshift dapat memutuskan untuk memanggil penulisan ulang kueri otomatis dari tampilan terwujud secara transparan untuk memberikan eksekusi kueri yang paling optimal dengan waktu kueri serendah mungkin.

Misalnya, Pengguna A membuat tampilan terwujud M1 pada tabel T1 dengan kueri. `SELECT * FROM T1` Pengguna A memiliki hak pilih penuh di T1. Pengguna A memberikan akses ke M1 ke semua pengguna, termasuk Pengguna B. Namun, ketika Pengguna B mencoba menanyakan T1 secara langsung, mereka ditolak aksesnya. Ini karena Pengguna B tidak memiliki hak SELECT pada T1.

Beberapa waktu kemudian, Pengguna B kembali mencoba untuk query T1, tetapi kali ini mendapatkan hasil kembali dari T1. Ini karena penulisan ulang kueri otomatis menggunakan tampilan terwujud menulis ulang kueri Pengguna B pada tabel T1 (`SELECT <cols> FROM T1`) ke kueri pada tampilan terwujud M1 (). `SELECT <cols> FROM M1` 

## Batasan
<a name="mv_auto-rewrite_limitations"></a>

Berikut ini adalah batasan untuk menggunakan penulisan ulang kueri otomatis dari tampilan terwujud:
+ Penulisan ulang kueri otomatis berfungsi dengan tampilan terwujud yang tidak mereferensikan atau menyertakan salah satu dari berikut ini:
  + Subkueri
  + Gabungan luar kiri, kanan, atau penuh
  + Tetapkan operasi 
  + Semua fungsi agregat, kecuali SUM, COUNT, MIN, MAX, dan AVG. (Ini adalah satu-satunya fungsi agregat yang bekerja dengan penulisan ulang kueri otomatis.)
  + Setiap fungsi agregat dengan DISTINCT
  + Fungsi jendela apa pun
  + PILIH Klausul DISTINCT atau HAVING
  + Tabel eksternal atau bersama
  + Pandangan terwujud lainnya
+ Penulisan ulang kueri otomatis menulis ulang kueri SELECT yang merujuk ke tabel Amazon Redshift yang ditentukan pengguna. Amazon Redshift tidak menulis ulang kueri berikut:
  + BUAT TABEL SEBAGAI pernyataan
  + Pernyataan SELECT INTO
  + Kueri pada katalog atau tabel sistem
  + Kueri dengan gabungan luar atau klausa SELECT DISTINCT
+ Jika kueri tidak ditulis ulang secara otomatis, periksa apakah Anda memiliki izin SELECT pada tampilan terwujud yang ditentukan dan [mv\_enable\_aqmv\_for\_session](r_mv_enable_aqmv_for_session.md) opsi disetel ke TRUE. 

  Anda juga dapat memeriksa apakah tampilan terwujud Anda memenuhi syarat untuk penulisan ulang kueri secara otomatis dengan memeriksa STV\_MV\_INFO. Untuk informasi selengkapnya, lihat [STV\_MV\_INFO](r_STV_MV_INFO.md).