Re: Simple DELETE on modest-size table runs 100% CPU forever

2019-11-14 Thread Andres Freund
Hi, On 2019-11-14 14:19:51 -0800, Craig James wrote: > I'm completely baffled by this problem: I'm doing a delete that joins three > modest-sized tables, and it gets completely stuck: 100% CPU use forever. > Here's the query: I assume this is intended to be an equivalent SELECT? Because you did m

Re: Simple DELETE on modest-size table runs 100% CPU forever

2019-11-14 Thread Justin Pryzby
On Thu, Nov 14, 2019 at 02:19:51PM -0800, Craig James wrote: > I'm completely baffled by this problem: I'm doing a delete that joins three > modest-sized tables, and it gets completely stuck: 100% CPU use forever. > Here's the query: > > explain analyze > select count(1) from registry.categories

Re: Simple DELETE on modest-size table runs 100% CPU forever

2019-11-14 Thread Michael Lewis
> If I leave out the "analyze", here's what I get (note that the > categories_staging_N table's name changes every time; it's > created on demand as "create table categories_staging_n(id integer)"). > How/when are they created? In the same statement? After create, are you analyzing these tables? I

Re: Simple DELETE on modest-size table runs 100% CPU forever

2019-11-14 Thread Alvaro Herrera
On 2019-Nov-14, Craig James wrote: > I'm completely baffled by this problem: I'm doing a delete that joins three > modest-sized tables, and it gets completely stuck: 100% CPU use forever. Do you have any FKs there? If any delete is cascading, and you don't have an index on the other side, it'd d

Simple DELETE on modest-size table runs 100% CPU forever

2019-11-14 Thread Craig James
I'm completely baffled by this problem: I'm doing a delete that joins three modest-sized tables, and it gets completely stuck: 100% CPU use forever. Here's the query: explain analyze select count(1) from registry.categories where category_id = 15 and id in (select c.id from registry.categor

Re: JSON path

2019-11-14 Thread Jesper Pedersen
Hi, On 11/14/19 1:04 PM, Tom Lane wrote: As of v12, that WITH will get flattened, so that you still end up with three invocations of jsonb_path_query_first, as EXPLAIN VERBOSE will show you. You could write "WITH foo AS MATERIALIZED ..." to prevent that, but then you'll need to stick the WHERE

Re: JSON path

2019-11-14 Thread Tom Lane
Jesper Pedersen writes: > We have a table which has a jsonb column in it. Each row contains a lot > of data in that column, so TOASTed. > We have to extract data from that column at different levels, so an > example query could look like > select >col1, >col2, > jsonb_path_query_first(

JSON path

2019-11-14 Thread Jesper Pedersen
Hi, We have a table which has a jsonb column in it. Each row contains a lot of data in that column, so TOASTed. We have to extract data from that column at different levels, so an example query could look like select col1, col2, jsonb_path_query_first(data,'$.lvl1.lvl2.lvl3.lvl4.lvl5.v

Re: Parallel Query

2019-11-14 Thread Luís Roberto Weck
Em 13/11/2019 19:08, Jeff Janes escreveu: On Wed, Nov 13, 2019 at 3:59 PM Luís Roberto Weck mailto:luisrobe...@siscobra.com.br>> wrote: Indeed, reducing the costs made the query run in parallel, but the improvement in speed was not worth the cost (CPU). Could you show the plan for t