raf writes:
> On Mon, Sep 14, 2020 at 05:39:57PM -0400, Tom Lane wrote:
>> On the other hand, the very same thing could be said of database names
>> and role names, yet we have never worried much about whether those were
>> encoding-safe when viewed from databases with different encodings, nor
>>
On Mon, Sep 14, 2020 at 05:39:57PM -0400, Tom Lane wrote:
> tutilu...@tutanota.com writes:
> > 1. All non-ANSI characters are turned into "?"s for application_name.
>
> Yeah, that's hard to do much with unfortunately. We cannot assume that
> all databases in an installation share the same encod
tutilu...@tutanota.com writes:
> 1. All non-ANSI characters are turned into "?"s for application_name.
Yeah, that's hard to do much with unfortunately. We cannot assume that
all databases in an installation share the same encoding, so for globally
visible strings like application_name, the only s
Regarding indexes, I recommend the website use-the-index-luke.com. That guy’s
other website about modern SQL is also great.
Regarding self-tuning, it was actually part of the original vision for
relational databases that they would do that, but I’m not aware of any modern
SQL database that does
I can’t for the life of me imagine how you arrived at this. SQLite is very
capable indeed.
>Its dialect of SQL is (deliberately) very similar to Postgres, featuring such
>niceties as
>recursive CTEs and window functions, and it can handle heavy use and
>multi-terabyte
> databases if you need (cf
On Sep 14, 2020, 13:22 -0700, tutilu...@tutanota.com, wrote:
> 3. The ability to embed PG to run in an automatic, quiet manner as part of
> something else. I know about SQLite, but it's extremely limited to the point
> of being virtually useless IMO, which is why I cannot use that for anything
>
Even though I highly appreciate that PostgreSQL, a database software which
doesn't cost money, exists *at all*, that fact is oftentimes overshadowed by a
small but important number of very frustrating issues which I consider to
largely ruin the overall "experience" of using PostgreSQL. I'd call
De: "Ron"
Para: "pgsql-general"
Enviadas: Segunda-feira, 14 de setembro de 2020 13:10:23
Assunto: Re: Effective IO Concurrency
On 9/14/20 11:03 AM, Laurenz Albe wrote:
> On Mon, 2020-09-14 at 10:39 -0300, luis.robe...@siscobra.com.br wrote:
>> In PostgreSQL 13, the way of using effective_i
On Mon, 14 Sep 2020 at 17:36, Michael Lewis wrote:
> Just curious, are you doing this in a trigger or in your application code?
> Either way, I'd think you could use the table record type to compare the temp
> vs real table values as an entire unit.
Application code - if I would put it in a tri
On 9/14/20 11:03 AM, Laurenz Albe wrote:
On Mon, 2020-09-14 at 10:39 -0300, luis.robe...@siscobra.com.br wrote:
In PostgreSQL 13, the way of using effective_io_concurrency has changed. Until
v12,
I used 200 for this value (using SSD drives). Using the new formula described
in
https://www.pos
On Mon, 2020-09-14 at 10:39 -0300, luis.robe...@siscobra.com.br wrote:
> In PostgreSQL 13, the way of using effective_io_concurrency has changed.
> Until v12,
> I used 200 for this value (using SSD drives). Using the new formula
> described in
> https://www.postgresql.org/docs/13/release-13.html
Just curious, are you doing this in a trigger or in your application code?
Either way, I'd think you could use the table record type to compare the
temp vs real table values as an entire unit.
with cte_indexes as(
select * from pg_indexes limit 10
)
select i1.indexdef, i2.tablename
from cte_indexe
For future reference, in the end I have just added a WHERE clause
comparing all fields with IS DISTINCT FROM. This seems to work well,
prevents any locks/WAL-generation and is about as fast as the previous
solution with suppress_redundant_updates_trigger().
Kind regards,
Mike
Hi!
In PostgreSQL 13, the way of using effective_io_concurrency has changed. Until
v12, I used 200 for this value (using SSD drives). Using the new formula
described in [ https://www.postgresql.org/docs/13/release-13.html |
https://www.postgresql.org/docs/13/release-13.html ] gives me 1176. Ho
On Mon, Sep 14, 2020 at 7:17 AM nandha kumar
wrote:
> Hi Team,
> I have the postgresql database with 11.4 Version in AWS RDS. Some of the
> columns have lattin collate format. I need to migrate the database to Azure
> postgresql and need to convert UTF8 column format.
>
> How to find which column
So it seems that when before triggers are handled, a SELECT FOR UPDATE
row-level lock is taken before the triggers are run. This causes a
write to the heap, as row-level locks are stored on-heap. This has the
unfortunate effect that suppress_redundant_updates_trigger() is not
able to prevent all wr
On Mon, 14 Sep 2020 at 06:32, Mike Noordermeer wrote:
> So it seems
> suppress_redundant_updates_trigger() does not entirely avoid writing
> _something_ to the blocks, and I don't know what it is and how to
> avoid it.
Looking at the pg_waldump output, it seems to write something
concerning locki
On Mon, 14 Sep 2020 at 06:03, Laurenz Albe wrote:
> These are probably the "hint bits" set on newly committed rows by the first
> reader.
> Note that te blocks are dirtied during the sequential scan, not during the
> update.
>
> You could try VACUUMing the tables before the update (which will se
18 matches
Mail list logo
