Hi,
I have atable with a "name" column, and I order it usually
order by regexp_match(name, 'regex1'), regexp_match(name, 'regex2')
orthe equivalent
order by (regexp_match(name, 'regex1'))[1], (regexp_match(name, 'regex2'))[2]
Is there a wayto create a function so the statement could read
select
Harmen writes:
> Works well enough. However, we now have an org_id which has > 10% of the rows,
> but only a handful rows where "deleted is null" matches (so the org has a lot
> of "deleted" contacts). The planner doesn't like this and it falls back to a
> full table scan for the above query.
> I
Dimitrios Apostolou writes:
> Please correct me if I'm wrong, as I'm a newcomer to PostgreSQL, but here
> is how I understand things according to posts I've read, and classical
> algorithms:
> + The Hash Join is fastest when one side fits in work_mem. Then on one
>hand you have a hash table l
Hi,
I'm trying to figure out why a certain query doesn't use a partial index.
The context:
The table has about 100M rows with "contacts". Every contact belongs to an
"org", and can be marked "deleted". Since we're generally only interested in
non-deleted contacts we have a (partial) index on the
On Fri, 13 Jan 2023, David Rowley wrote:
I'd expect reducing random_page_cost to make the Mege Join cheaper as
that's where the Index Scan is. I'm not quite sure where you think the
random I/O is coming from in a batched hash join.
Thanks for the feedback, indeed you are right! Decreasing ra
On 2023-01-14 11:34:13 +0530, jian he wrote:
> Once we have the diff table, we perform set-based DELETE and INSERT
> operations against the materialized view, and discard both temporary
> tables.
>
>
> Here the temporary tables are "discard" meaning the temporary tables are
> deleted
