> If there's no data compressed
> using the compression method you dropped, everything is cool -
> otherwise everything is broken and there's no way to recover.
> The only obvious alternative is to disallow DROP altogether (or make it
> not really DROP).
Wouldn't whatever was using the
So from following this discussion and others focused on making the
planner "smarter", there is always an argument to be had over wasting
planner cycles, and it's always a hard fought battle to get any changes made.
Now, i'm speaking without any knowledge of the Postgres internals, so
please bear
> I can't get very excited about this one either, though I do believe it
> can arise as the author says, "when you build complex views and JOIN
> them to each other". Maybe I'm not excited about it because I've not
> needed it :)
This is one that I know would help with my database. There is a
Hopefully it's alright for me to post this here, please let me know if not.
I ran across an article on blog.jooq.org comparing all the major RDBMS'
with their ability to optimize away unnecessary work with queries which are
less than optimal, and saw some discussion on hackernews and reddit, but
I know that for my use-cases, having both options available would be very
appreciated. The vast majority of the computed columns I would use in my
database would be okay to compute on read. But there are for sure some
which would be performance prohibitive to have compute on read, so i'd
rather
My understanding is that global indexes allow foreign keys to work
naturally with partitioned tables, or tables in an inheritance hierarchy.
That is pretty big IMO, as it allows you to partition a table without
making a trade-off in your database integrity.
>
> I'll give it a few days for objections before reverting.
>>
>
> I can only say that the lack of this feature comes up on a weekly basis on
> IRC, and a lot of people would be disappointed to see it reverted.
>
Not that my opinion matters, but I was very much looking forward to this
feature in
>From a user's perspective:
>I think most people prefer #2 because:
>
>* most users writing queries prefer #2
> >* most users assume full optimization and it seems natural to turn
> > _off_ an optimization via a keyword
> >* while some queries can be inlined, all queries can be
>
> BTW, it just occurred to me that having this separation would make it
> relatively easy to support re-directing DML queries from a replica to the
> master; if the backend throws the error indicating you tried to write data,
> the connection layer could re-route that.
This also sounds like it
>
> There may be some situations where crawling the indexes a row at a
> time will perform better than this by enough to want to retain that
> option.
If an index existed, wouldn't it still be able to use that in the set-based
implementation? Is there something which would make doing the check
>
> The delete of about one million rows from a "parent" table with no
> matching rows in the "child" table, and no index on referencing
> column in the child table, took 24:17.969 using current triggers
> and 00:03.262 using the set-based triggers. Yes, that reduces
> current run time for that
So I apologize in advance if I didn't follow the processes exactly, I was
going to attempt to review this to move it along, but ran into issues
applying the patch cleanly to master. I fixed the issues I was having
applying it, and created a new patch (attached).
Managed to test it out after I
Just throwing an anecdote out there, but my company uses UUID for primary
keys on every table in the DB. While int4 is for sure more popular, it
would be nice if there weren't even more reasons to "force" people in that
direction. I know I started regretting the decision to go with UUID
primary
13 matches
Mail list logo
