Hi Bryn,
On Mon, 30 May 2022 at 03:12, Bryn Llewellyn wrote:
...
>
> Try this:
>
>snapshot -> ‘employee’->>’date_of_birth’
>
Syntactically, that works:
create index bryn on paiyroll_payrun using btree ((snapshot ->
'employee'->>'date_of_birth'));
But IIUC it is looking for 'date_of_bir
Hi Shaheed,
> WHAT GOES HERE
imho check the: *jsonb_path_query_array( jsonb_col,
'$.employee.*.date_of_birth' ) *
may example:
CREATE TABLE jsonb_table (
id serial primary key,
jsonb_col JSONB
);
INSERT INTO jsonb_table(jsonb_col)
VALUES
('{"stuff": {},"employee": {"8011": {"date_
> In principle, I believe this allows index-assisted access to keys and
> values nested in arrays and inner objects but in practice, it seems
> the planner "often" decides to ignore the index in favour of a table
scan.
part II. index usage ; see the "*Bitmap Index Scan on jpqarr_idx*"
SET enab
Hi All,
I would appreciate some advice on adding data to logically replicated
tables on the subscriber. I am worried about contention between
writes from local data loading and replication.
We have 14 publisher databases (all with identical schema) that are
constantly receiving new data. The
Imre,
I'm gradually working my way into the combination of SQL, JSONB and
jsonpath that this involves even without the indexing, but this looks
very helpful/promising, especially on the indexing. Thanks a lot for
the input,
Shaheed
On Mon, 30 May 2022 at 11:50, Imre Samu wrote:
>
> > In princip
On Sat, May 28, 2022 at 1:54 PM Shaheed Haque
wrote:
>
And how can I understand the dreadful amount of
> time (of course, this is just on my dev machine, but still...)? Is
> there a way to see/tweak what TOAST costs or indeed to confirm if it
> is even in use?
>
Turn on track_io_timing, and the
On Fri, May 27, 2022 at 3:01 PM Don Seiler wrote:
I've been reading tales of autovacuum taking an AccessExclusiveLock when
> truncating empty pages at the end of a table. I'm imagining that updating
> every row of a table and then rolling back would leave all of those rows
> empty at the end and
El día miércoles, mayo 25, 2022 a las 10:38:24a. m. -0400, Tom Lane escribió:
> Ravi Krishna writes:
> >> No. PostgreSQL may remove a dead row, but a dead row is by definition
> >> no longer visible, so it wouldn't be found by a query.
>
> > I am wondering whether it is a good practice to use C
