Re: [PERFORM] No index only scan on md5 index

I appreciate the response Tom, and you are correct that the workaround would not work in my case. So no index expressions can return the their value without recomputing without that work around? I learn something new every day it seems. Thank you for the alternate method. -Adam On Wed, Nov 25,

Re: [PERFORM] No index only scan on md5 index

Main reason I was hoping to not do that, is the value that would be stored in that column is dependent on what is stored in the attachment_bytes column, so to be 100% sure it's correct, you'd need that column controlled by a trigger, disallowing any explicit inserts or updates to the value. Was hav

Re: [PERFORM] No index only scan on md5 index

Adam Brusselback writes: > CREATE TABLE attachment > ( > attachment_id uuid NOT NULL DEFAULT gen_random_uuid(), > attachment_name character varying NOT NULL, > attachment_bytes_size integer NOT NULL, > attachment_bytes bytea NOT NULL, > CONSTRAINT attachment_pkey PRIMARY KEY (attachment_

Re: [PERFORM] No index only scan on md5 index

On Wednesday, November 25, 2015, Adam Brusselback wrote: > Hey all, > > I have an attachment table in my database which stores a file in a bytea > column, the file name, and the size of the file. > > Schema: > CREATE TABLE attachment > ( > attachment_id uuid NOT NULL DEFAULT gen_random_uuid(),

[PERFORM] No index only scan on md5 index

Hey all, I have an attachment table in my database which stores a file in a bytea column, the file name, and the size of the file. Schema: CREATE TABLE attachment ( attachment_id uuid NOT NULL DEFAULT gen_random_uuid(), attachment_name character varying NOT NULL, attachment_bytes_size integ

Re: [PERFORM] Query that took a lot of time in Postgresql when not using trim in order by

My database version is 9.3 but I have test with 9.4 too with the same result, and I have test changing that parameter without success. I want to know what does have to do the trim with the different query plans? 2015-11-25 13:35 GMT-03:00 Evgeniy Shishkin : > > What is your Postgres version? > >

Re: [PERFORM] Query that took a lot of time in Postgresql when not using trim in order by

> What is your Postgres version? > Do you have correct statistics on this tables? > Please show yours execution plans with buffers i.e. explain > (analyze,buffers) ... > Fast: Sort (cost=193101.41..195369.80 rows=907357 width=129) (actual time=3828.176..3831.261 rows=43615 loops=1) Outp

Re: [PERFORM] Query that took a lot of time in Postgresql when not using trim in order by

On 25.11.2015 17:15, Blas Pico wrote: I have a query that produce a different query plan if I put a trim in one of the columns in the order by. When i put the trim in any column it use hashaggregate and took 3 seconds against 30 when not. Is wear because the columns is clean not need to

[PERFORM] Query that took a lot of time in Postgresql when not using trim in order by

I have a query that produce a different query plan if I put a trim in one of the columns in the order by. When i put the trim in any column it use hashaggregate and took 3 seconds against 30 when not. Is wear because the columns is clean not need to be trimmed, I have check that. The problem