Re: [EXT] Re: Why using a partial index is doing slightly more logical I/O than a normal index

2023-05-03 Thread Jeff Janes
On Wed, May 3, 2023 at 2:00 PM Dirschel, Steve < steve.dirsc...@thomsonreuters.com> wrote: > Thanks for the reply Jeff. Yes- more of an academic question. Regarding > this part: > > > >Index Cond: ((workflow_id = 1070) AND ((status)::text = ANY >

Re: [EXT] Re: Why using a partial index is doing slightly more logical I/O than a normal index

2023-05-03 Thread Tom Lane
"Dirschel, Steve" writes: > There are 2,981,425 rows where workflow_id = 1070. Does that change your > theory of using an “in-index filter” for that plan? When you say there was a > bit of speculation on the “boundard condition” vs “in-index filter” is the > speculation on if Postgres has 2

RE: [EXT] Re: Why using a partial index is doing slightly more logical I/O than a normal index

2023-05-03 Thread Dirschel, Steve
Thanks for the reply Jeff. Yes- more of an academic question. Regarding this part: Index Cond: ((workflow_id = 1070) AND ((status)::text = ANY ('{NOT_STARTED,PAUSED,PENDING,RUNNING}'::text[]))) Filter: (deleted_millis <= 0) Buffers: shared hit=24 For this usage, the =ANY is applied

Re: Why using a partial index is doing slightly more logical I/O than a normal index

2023-05-03 Thread Jeff Janes
Because both the actual times and the expected costs are so similar to each other, I am assuming you are asking this as more of an academic question than a practical one. If it is actually a practical matter, you should find a better example to present to us. On Wed, May 3, 2023 at 9:17 AM

Why using a partial index is doing slightly more logical I/O than a normal index

2023-05-03 Thread Dirschel, Steve
Table definition: workflow_db=> \d workflow_execution_test Table "public.workflow_execution_test" Column | Type | Collation | Nullable | Default