Re: Slow index creation

Why not create a table with cols a, b, c and d. Where you insert a row for
each combination and key and index abc then return d?

ons. 24. feb. 2021, 21:15 skrev Paul van der Linden <
paul(dot)doskabouter(at)gmail(dot)com>:

> Thanks for all the suggestions,
>
> When the server is not in use for mission-critical work, I'll definitely
> going to do some testing based on your ideas.
> Will let you know what comes out of that
>
> Cheers,
> Paul
>
> On Thu, Feb 18, 2021 at 6:49 PM hubert depesz lubaczewski <
> depesz(at)depesz(dot)com> wrote:
>
>> On Thu, Feb 18, 2021 at 10:24:25AM -0700, Michael Lewis wrote:
>> > [1]
>> https://www.depesz.com/2010/03/18/profiling-stored-proceduresfunctions/
>> >
>> > Thanks for this reference. I enjoy your blog, but haven't made the time
>> to read all the archives somehow. Stuff doesn't stick very
>> > well when it isn't yet "needed" info besides.
>> > I have seen overhead from 'raise notice' in small functions that are
>> sometimes called many thousands of times in a single query, but
>> > hadn't done the test to verify if the same overhead still exists for
>> raise debug or another level below both client_min_messages
>> > and log_min_messages. Using your examples, I saw about .006 ms for each
>> call to RAISE DEBUG with a client/log_min as notice/warning.
>>
>> Sure, this overhead is definitely possible, but kinda besides the point
>> - there will be some slowdowns in other places, and it will be good to
>> track them.
>> That's why I suggested to do it on small sample of data.
>>
>> Best regards,
>>
>> depesz
>>
>>