Re: blending fast and temp space volumes

2018-02-21 Thread Craig James
On Wed, Feb 21, 2018 at 7:53 AM, Rick Otten wrote: > Some of my data processes use large quantities of temp space - 5 or 6T > anyway. > > We are running in Google Cloud. In order to get the best performance out > of all of my queries that might need temp space, I've configured temp space > on a

Irrelevant columns cause massive performance change

2018-03-16 Thread Craig James
Here's a weird one I can't figure out: the definitions of several columns of a view, which are not used in a query at all, have a massive effect on the query planner, causing it to choose a seqscan over the largest table in our database when it should be using the primary key for the join. Backgrou

Re: Irrelevant columns cause massive performance change

2018-03-16 Thread Craig James
On Fri, Mar 16, 2018 at 1:50 PM, Andres Freund wrote: > Hi, > > On 2018-03-16 13:37:05 -0700, Craig James wrote: > > The timing of the second query is excellent, and is what I expected. I > > don't understand why including a function-defined column in the view > w

Latest advice on SSD?

2018-04-09 Thread Craig James
One of our four "big iron" (spinning disks) servers went belly up today. (Thanks, Postgres and pgbackrest! Easy recovery.) We're planning to move to a cloud service at the end of the year, so bad timing on this. We didn't want to buy any more hardware, but now it looks like we have to. I followed

Re: Latest advice on SSD?

2018-04-10 Thread Craig James
On Tue, Apr 10, 2018 at 12:21 AM, Andreas Joseph Krogh wrote: > På tirsdag 10. april 2018 kl. 04:36:27, skrev Craig James < > cja...@emolecules.com>: > > One of our four "big iron" (spinning disks) servers went belly up today. > (Thanks, Postgres and pgbackrest! Ea

Re: propose web form for submission of performance problems

2018-05-24 Thread Craig James
On Thu, May 24, 2018 at 4:57 PM, Justin Pryzby wrote: > What would the list think of a web form for submitting problems the > performance > list, similar to the pgsql-bugs form? > > Alternately, or perhaps additionally, a script (hopefully bundled with > postgres) which collects at least the non-

UNION causes horrible plan on JOIN

2019-10-28 Thread Craig James
On Postgres 9.6 (config below), I have a case I don't understand: three tables that can be separately queried in milliseconds, but when put together into one view using UNION, take 150 seconds to query. Here's the rough idea (actual details below): create view thesaurus as (select id,

Re: UNION causes horrible plan on JOIN

2019-10-28 Thread Craig James
On Mon, Oct 28, 2019 at 3:45 PM Justin Pryzby wrote: > On Mon, Oct 28, 2019 at 03:40:58PM -0700, Craig James wrote: > > On Postgres 9.6 (config below), I have a case I don't understand: three > > tables that can be separately queried in milliseconds, but when put > > to

Re: UNION causes horrible plan on JOIN

2019-10-28 Thread Craig James
On Mon, Oct 28, 2019 at 4:31 PM Justin Pryzby wrote: > On Mon, Oct 28, 2019 at 04:30:24PM -0700, Craig James wrote: > > On Mon, Oct 28, 2019 at 3:45 PM Justin Pryzby > wrote: > > > > > On Mon, Oct 28, 2019 at 03:40:58PM -0700, Craig James wrote: > > > > O

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: Simple DELETE on modest-size table runs 100% CPU forever

2019-11-15 Thread Craig James
On Thu, Nov 14, 2019 at 2:29 PM Andres Freund wrote: > 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

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

2019-11-15 Thread Craig James
On Fri, Nov 15, 2019 at 2:45 PM Jeff Janes wrote: > On Thu, Nov 14, 2019 at 5:20 PM 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 &

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

2019-11-16 Thread Craig James
Problem solved ... see below. Thanks everyone for your suggestions and insights! On Sat, Nov 16, 2019 at 7:16 AM Jeff Janes wrote: > On Fri, Nov 15, 2019 at 7:27 PM Craig James wrote: > >> On Fri, Nov 15, 2019 at 2:45 PM Jeff Janes wrote: >> BTW, I'll note at t

Re: Postgres backup tool recommendations for multi-terabyte database in Google Cloud

2019-12-05 Thread Craig James
oud equivalent is for low-cost storage) backup with just modest bandwidth usage. In a cloud environment, you can do this on modestly-priced hardware (a few CPUs, modest memory). In the event of a failover, unmount your backup disk, spin up a big server, mount the database, do the incremental res

Legal disclaimers on emails to this group

2019-12-06 Thread Craig James
(I've changed the original subject, "autovacuum locking question", of the sender's email so as not to hijack that thread.) On Thu, Dec 5, 2019 at 2:26 PM Mike Schanne wrote: > Hi, > > I am investigating a performance problem... > ... This email is non-binding, is subject to contract, and neither