[syndicated profile] taurus_ek_lj_feed
Давно не писал здесь, потому что аки буриданов осел, стоял перед проблемой выбора: каннибализм в греческой мифологии или картинки от AI Sora. В результате склонился на модное, потому что никак не дочитаю Л.Ф.Воеводского на людоедскую тему (1870 какой-то год, однако), а написать что-то надо.

AI Sora от OpenAI умеет делать картинки по текстовому запросу, и получается неплохо. У меня на некоторых страницах сайта не хватает иллюстраций, так что для меня это просто выход. И вообще забавно.

Я показывал Аглаю, Мастусия, Гекату, а теперь - ихтиокентавры.





Полиморфные миксаморфы, схожие с кентаврами, но обитавшие в морях. Человеческий торс, лошадиное тело, хвост рыбы, плавники, крабовые клешни на голове, как-то так.


Заставить Sora нарисовать такое сложно: она считает подобный образ неприличным, потворствующим аморальному и жестокому. Но зато ей можно подсунуть мозаику и попросить перерисовать.

20251003_2036_Мозаика Ихтиокентавр_remix_01k6nj8ajbenvsvnhym9k9mgea.jpg

Еще пример перерисовки, ихтиокентавры Афрос и Битос



Вот что получилось

20251005_1633_Венера в мозаике_remix_01k6t95bj1f5hr7301xc3yvy56.jpg

Ну и наконец, замечательное рождение Афродиты в сопровождении ихтиокентавров. Это, конечно, тоже страшно аморально, тлетворно и деторазвращающе, но если не писать неприличных слов типа "обнаженная" или "в стиле ню", а назвать имя "Афродита", то ИИ бодро идет по ренесансным прототипам и выбирает, в общем, правильное. За эту работу я ему пятёрку ставлю.

20251003_2117_Мифическая сцена_remix_01k6nmk9gvep592ehvzyv7sdsf.jpg



Продолжение скоро, оставайтесь с нами!

Расизм

Oct. 21st, 2025 09:26 pm
[syndicated profile] temalebedev_feed

Posted by temalebedev

Практически все народы на свете - расистские. На этом фоне особенно выделяются культуры, где пытаются стереть различия между расами и народами, заставив всех любить всех. А точнее - заставив большинство любить любые виды меньшинств.

Суровая правда жизни заключается в том, что народам свойственно испытывать ксенофобию - разной степени нелюбовь к другим народам и культурам. Даже шведы стебут норвегов, даже поляки издеваются над украинцами. Китайцы ненавидят негров, негры ненавидят азиатов.

Американские корпорации могут заставить всех сотрудников формально быть толерантными, но все народы, которых типа надо любить, сами мало кого любят.

Памирские таджики бесятся, что их считают таджиками. Простые таджики ненавидят узбеков. Кавказские народы терпеть не могут такие оттенки своих соседей, которые вообще никто из других регионов не различит.

Органичная толерантность случается только в двух случаях: когда ты один попадаешь в полностью чужую культуру (и понимаешь, что там не так уж и страшно) или когда кто-то один из чужой культуры попадает в твою среду (и понимаешь, что он не такой и страшный). Если происходит лавинообразное вливание чужого народа в любой другой народ, то возникает неизбежный пиздец.

Насильно мил не будешь. Если ты представитель большинства в развитой стране, то у тебя мало возможностей быть расистом. А если ты представитель меньшинства, то наслаждайся вседозволенностью - ты застрахован от претензий. Пока другое меньшинство не надает тебе пиздюлей.

О чаевых

Oct. 22nd, 2025 12:55 pm
[syndicated profile] hardsign_lj_feed

Нужно ли давать чаевые — вопрос холиварный. Кто хотел — давно обсудил, кого надо — давно забанили. У меня другой вопрос.

Что человек чувствует, когда даёт или не даёт чаевые?

Как по мне, если кто-то пишет «я уже заплатил, с какой стати я должен давать что-то ещё» — это нищеброд самого худшего разбора. Не потому нищеброд, что не оставляет чаевых, а потому, что придаёт этому столько значения и вытаскивает свою боязнь потратить лишнюю копейку (или обнаружить, что копейки нет) в публичное поле.

Возможность оставить чаевые даёт человеку почувствовать себя состоятельным. Мол, для меня — незаметные копейки, а официанту/таксисту/парикмахеру/носильщику/итд/итп — заметная благодарность, не говоря уже о моральном удовлетворении от высокой оценки. В общем, я дорожу собственной самооценкой и чаевые стараюсь оставлять.

Правда, если чаевые обязательны, как в Америке, меня это бесит. Вполне возможно, это потому, что по американским меркам и я — нищеброд...

[syndicated profile] planet_pgsql_short_feed

In the last edition of this blog, the passenger list data from the HMS Titanic was loaded into a preliminary database. Now it is time to refine.

I am using DBeaver Enterprise 25.2.0. PostgreSQL 18, and Github Copilot with Gpt-4. 

Prompt: Any recommendations on improving this table for storage efficiency? This prompt was entered into the DBeaver AI Assistant.

To improve the storage efficiency of the "titanic" table, we can consider the following recommendations:


### 1. **Optimize Data Types**

- **"PassengerId"**: If the number of passengers is not expected to exceed 2,147,483,647, the `int4` type is fine. However, if the range is smaller (e.g., less than 32,767), you could use `int2` (smallint) to save space.

- **"Survived"**: Since this is likely a binary value (0 or 1), you can use `boolean` instead of `int4`.

- **"Pclass"**: If the class is limited to 1, 2, or 3, you can use `int2` (smallint) instead of `int4`.

- **"Sex"**: If this column only contains "male" and "female", consider using an `enum` type or a `char(1)` ('M' or 'F') to save space.

- **"Age"**: If precision beyond one decimal place is not required, consider reducing the precision or using `numeric` with a defined scale.

- **"SibSp" and "Parch"**: If these values are small integers (e.g., number of siblings/spouses or parents/children), you can use `int2` (smallint).

- **"Ticket"**: If ticket numbers are of fixed length, consider using `char(n)` instead of `varchar`.

- **"Fare"**: If precision beyond two decimal places is not required, consider using `numeric` with a defined scale (e.g., `numeric(10,2)`).

- **"Cabin"**: If cabin identifiers are of fixed length, consider using `char(n)` instead of `varchar`.

- **"Embarked"**: If this column only contains a small set of values (e.g., 'C', 'Q', 'S'), consider using an `enum` type or `char(1)`.


Comment: This is what I was looking for. Saving sp

[...]
[syndicated profile] planet_pgsql_short_feed
On 20th of October 2025, Masahiko Sawada committed patch: Support COPY TO for partitioned tables.   Previously, COPY TO command didn't support directly specifying partitioned tables so users had to use COPY (SELECT ...) TO variant.   This commit adds direct COPY TO support for partitioned tables, improving both usability and performance. Performance tests show … Continue reading "Waiting for PostgreSQL 19 – Support COPY TO for partitioned tables."

Плохая дикция

Oct. 21st, 2025 09:25 pm
[syndicated profile] temalebedev_feed

Posted by temalebedev

Я несколько раз в жизни встречал пару людей с настолько омерзительной дикцией, что просто вообще нихуя непонятно, что человек говорит.

Мне кажется, надо таких людей посадить в студию и устроить им ток-шоу. Или подкаст такой сделать.

Нечленораздельношоу.

[syndicated profile] pavel_kosenko_lj_feed
Армения

Проявил очередной ролик Adox Color Implosion из очередной поездки по Армении. Фотки, как всегда, фигня. Но душевно!

Армения, Октябрь 2025
Проявка и скан – Karmir Film Lab, Ереван

2.
Армения

3.
Армения

4.
Армения

5.
Армения

6.
Армения

7.
Армения

8.
Армения

9.
Армения

10.
Армения

Выборы 2.0

Oct. 21st, 2025 08:55 am
[syndicated profile] temalebedev_feed

Posted by temalebedev

Сейчас выборы неправильно проводятся.

Сначала надо объявлять правила и разыгрываемые должности.

За > 50 % - победа. Пост мэра, губернатора или президента.

За 30-40 % - пост заместителя, начальника департамента или министра.

За 10 % - поработай префектом.

За 5 % - в Петропавловске-Камчатском посиди пару лет на ЖКХ.

За единичные проценты - на пять лет завскладом. Набираться административного опыта.

Отказаться нельзя. Не нравится - не участвуй. Тогда количество пиздаболов и участвующих ради пиара резко сократится. И останутся только те, кому нужно.

[syndicated profile] planet_pgsql_short_feed

Belgium Meetup: Tuesday, 14 October 2025 - organized by Boriss Mejias & Stefan Fercot

Speakers:

  • Niradj Selvam
  • Stefan Fercot

Погодный синдром

Oct. 21st, 2025 08:54 am
[syndicated profile] temalebedev_feed

Posted by temalebedev

У меня прикольный синдром - я всегда жду, когда в конце выпуска новостей покажут температуру в Москве, но уже через две секунды не могу вспомнить, что там было.

[syndicated profile] hardsign_lj_feed

Как известно, курьеры и таксисты зарабатывают бешеные бабки. Пока они не подвинули с пьедестала айтишников, надо срочно ввести налоги, пошлины, утильсборы, патенты и прочая и прочая и прочая.

Если с курьерами я не взаимодействую никак и систему их оплаты не представляю, то на такси иногда езжу. И как-то на днях от нечего делать решил перемножить в уме пару чисел.

Часовая поездка стоит около полутора тысяч. Ну понятно плюс-минус, но нам же для прикидки?

Допустим, водитель крутит баранку 8 часов без перерыва и берёт заказ немедленно после завершения предыдущего (а оно обычно так и бывает — «водитель завершает предыдущую поездку и направляется к вам»). Итого выручка составляет... ну, давайте прямо вот от щедрот 10 тысяч в день, хотя это должен быть очень удачный день.

30% забирает агрегатор, то есть остаётся 7000. Прямо скажем, неплохой гешефт — сидеть в тёплом офисе с кофемашиной и турником во дворе, не возиться на холоде с промасленными железками и иметь треть со всех заказов.

Средняя скорость движения по городу два ли превосходит 30 км/ч, т. е. в день машина проезжает ну пусть 250 км. «4 литра на сотню» — это реклама для тех, кто ни разу не открывал бензобак. Даже 10 — это почти фантастика, но мы сегодня щедрые (за чужой-то счёт!) 25 литров 95-го бензина — это минус 1700 рублей, то есть на руках у водителя остаётся 5300.

Работать 30 дней в месяц — выглядит красиво, особенно на экране. В реальности даже 25 рабочих дней — это тяжело. Но допустим так и получим 132500 рублей в месяц. В принципе, это могли бы быть нормальные деньги за тяжёлый, но неквалифицированный труд, но...

Но машина не вечна, и если ты не хочешь в один прекрасный момент остаться с грудой железа на руках без средств заработка, надо откладывать на новую машину, это называется «амортизация». Давайте возьмём, например, какой-нибудь Haval Jolion, который стоит 2,4 миллиона. Будем оптимистами и посчитаем, что его хватит на 5 лет, но не будем фантазёрами и не будем надеяться, что через пять лет в такси машина будет хоть чего-то стоить. Пусть даже у таксиста собственная машина, и владелец машины не хочет получить свой кусок прибыли. Итого 40 тысяч в месяц — амортизация, что оставляет водителю 92500 рублей.

Я уже написал многабукафф, поэтому предлагаю читателю самостоятельно вычесть из этой суммы мойку, техническое обслуживание машины, налоги и обязательный для такси техосмотр. А если и после этого заработок водителя покажется огромным, вспомните, что машина за 5 лет ни разу не сломалась, сам водитель ни разу не заболел, а камера ни разу не зафиксировала наезд на сплошную или превышение скорости на 20,5 км/ч...

Закон капучино

Oct. 20th, 2025 09:46 pm
[syndicated profile] temalebedev_feed

Posted by temalebedev

Маленький капучино всегда вкуснее большого.

Большой капучино есть во всех кофейнях, потому что его часто заказывают.

Но любой настоящий любитель капучино, если ему недостаточно маленькой чашки, берет две маленькие чашки, но никогда не одну большую.

Проверить мою абсолютную правоту просто: в любой любимой кофейне закажите большой и маленький капучино одновременно. И попробуйте то и то.

Только не в макдачной и не в старбаксообразных заведениях! Там заваривают кипятком кошачьи какашки, пить это нельзя ни из какой чашки.

[syndicated profile] planet_pgsql_short_feed

Sometimes a descending index is the better choice: a man is trying to read an alphabetically sorted list upside down
© Tobi Albe 2025

PostgreSQL can scan B-tree indexes in both directions. That means that there is little need to create a index in descending order (one created with the DESC clause). However, there are some cases where you need a descending index. There are also some corner cases where a descending index performs better than an ascending one. Follow me to explore use cases for the DESC clause!

Mixed ORDER BY clauses

This is the obvious use case for a descending index. There is a reason why CREATE INDEX offers the same clauses as ORDER BY: if you want a B-tree index to support an ORDER BY clause, its sorting order must match the ORDER BY clause precisely. So, to support a query like

SELECT col2 FROM tab
ORDER BY col1 DESC NULLS LAST;

you need to create an index like

CREATE INDEX tab_col1_desc_idx
ON tab (col1 DESC NULLS LAST);

But since PostgreSQL can scan indexes in both directions, the following index will also work:

CREATE INDEX tab_col1_idx
ON tab (col1 NULLS FIRST);

However, you cannot avoid the DESC clause if you want to support an ORDER BY clause with both ascending and descending columns:

SELECT col2 FROM tab
ORDER BY col1 DESC, col2 NULLS LAST;

In a previous article, I wrote some more about mixed ORDER BY clauses in the context of keyset pagination. There, you can find some more creative ideas for using descending indexes.

Descending indexes for space efficiency

This is a somewhat more exotic use case. I'll demonstrate it with the following table:

CREATE UNLOGGED TABLE large(
   id bigint NOT NULL
);

CREATE INDEX large_id_idx ON large(id);
CREATE INDEX large_id_desc_idx ON large (id DESC);

One of these two indexes is clearly redundant. But look what happens if I INSERT rows in descending order:

INSERT INTO large (id)
SELECT * FROM generate_series(10000000, 1, -1);

SELECT ind AS index_name,
       pg_size_pretty(pg_relation_size(ind)) AS index_size
FROM (VALUES ('large_id_idx'::regclass),
             ('large_id_desc_idx'::regclass)) AS i(ind);

    index_na
[...]
[syndicated profile] planet_pgsql_short_feed

For many Postgres DBAs, Kubernetes feels like a new, complex world. But what if your existing skills were the key to unlocking it? This article demystifies cloud-native Postgres by revealing a first handful of kubectl and kubectl cnpg commands that act as your direct translator. I’ll move past the intimidating YAML to focus on the practical, imperative commands you’ll actually use to troubleshoot, inspect, and even perform a production switchover. You’ll see how your core DBA work maps directly to this new environment, helping you build the confidence to take the next step into the cloud-native world.

[syndicated profile] planet_pgsql_short_feed

In this series, we talk about the many different ways you can speed up PostGIS. Today let’s talk about looking across the queries with pg_stat_statements and some basic tuning.

Showing Postgres query times with pg_stat_statements

A reasonable question to ask, if you are managing a system with variable performance is: “what queries on my system are running slowly?”

Fortunately, PostgreSQL includes an extension called “pg_stat_statements” that tracks query performance over time and maintains a list of high cost queries.

CREATE EXTENSION pg_stat_statements;

Now you will have to leave your database running for a while, so the extension can gather up data about the kind of queries that are run on your database.

Once it has been running for a while, you have a whole table – pg_stat_statements – that collects your query statistics. You can query it directly with SELECT * or you can write individual queries to find the slowest queries, the longest running ones, and so on.

Here is an example of the longest running 10 queries ranked by duration.

SELECT
  total_exec_time,
  mean_exec_time,
  calls,
  rows,
  query
FROM pg_stat_statements
WHERE calls > 0
ORDER BY mean_exec_time DESC
LIMIT 10;

While “pg_stat_statements” is good at finding individual queries to tune, and the most frequent cause of slow queries is just inefficient SQL or a need for indexing - see the first post in the series.

Occasionally performance issues do crop up at the system level. The most frequent culprit is memory pressure. PostgreSQL ships with conservative default settings for memory usage, and some workloads benefit from more memory.

Shared buffers

A database server looks like an infinite, accessible, reliable bucket of data. In fact, the server orchestrates data between the disk – which is permanent and slow – and the random access memory – which is volatile and fast – in order to provide the illusion of such a system.

alt

When the balance between slow storage and fast memory is out of whack, syste

[...]

Ibrar Ahmed: Scaling Postgres

Oct. 20th, 2025 04:38 am
[syndicated profile] planet_pgsql_short_feed

Postgres has earned its reputation as one of the world's most robust and feature-rich open-source databases. But what happens when your application grows beyond what a single database instance can handle? When your user base explodes from thousands to millions, and your data grows from gigabytes to terabytes?This is where Postgres scaling becomes critical. The good news is that Postgres offers multiple pathways to scale, each with its own advantages and use cases. Since pgEdge Distributed Postgres and pgEdge Enterprise Postgres are 100% Postgres, all of the scaling techniques that follow also apply to your pgEdge cluster.In this comprehensive guide, we'll explore three fundamental scaling approaches:

  • vertical scaling
  •  (enhancing the power of your current server)
  • horizontal
  •  
  • scaling
  •  (adding additional servers)
  • and
  • high availability
  •  strategies (ensuring your system remains online in the event of failures).

Postgres Architecture

Before diving into scaling strategies, it's crucial to understand how Postgres works under the hood. Unlike some databases that use threads, Postgres uses a process-based architecture. This design choice has significant implications for how we approach scaling.

The Postgres Process Family

When Postgres runs, it creates several specialized processes, each with a specific job:
  • Postmaster
  • : The master process that coordinates everything else
  • Backend processes
  • : One for each client connection - they handle your SQL queries
  • WAL Writer
  • : Manages the Write-Ahead Log, ensuring data durability
  • Checkpointer
  • : Periodically flushes data from memory to disk
  • Background Writer
  • : Smooths out disk I/O by gradually writing data
  • Autovacuum Workers
  • : Clean up dead rows and maintain database health
  • Replication processes
  • : Handle data copying to other servers
You can see these processes in action on any Postgres server:Understanding this architecture is crucial because[...]
[syndicated profile] planet_pgsql_short_feed


In August of this year, I published a blog entitled PostgreSQL’s incredible trip to the top with developers which shows how Postgres has become the most used, most loved and most desired database according to the Stack Overflow annual developer survey. In that blog I said, I want to do the series in two parts. After some thought, I have decided to make it a 3 part series. It will break down as follows:

Part 1: The aforementioned blog was just the facts regarding Postgres becoming the most loved, most desired and most used database by developers according to the stack overflow survey. 


Part 2

[syndicated profile] temalebedev_feed

Posted by temalebedev

- Посмотри на любое мнение или оценку ровно с противоположной точки зрения

- Проверь мнение у незаинтересованного специалиста (например, перед любой врачебной процедурой или операцией)

- Не ходи в супермаркет голодным

- Подожди с высказыванием своего мнения пару дней (за это время обычно вообще все меняется)

Profile

egorius: (Default)
egorius

September 2025

M T W T F S S
1234567
891011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 23rd, 2025 04:59 am
Powered by Dreamwidth Studios