Re: [HACKERS] Custom compression methods

2017-11-05 Thread Adam Brusselback
> 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

Re: [HACKERS] Discussion on missing optimizations

2017-10-13 Thread Adam Brusselback
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

Re: [HACKERS] Discussion on missing optimizations

2017-10-08 Thread Adam Brusselback
> 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

[HACKERS] Discussion on missing optimizations

2017-10-06 Thread Adam Brusselback
Hopefully it's alright for me to post this here, please let me know if not. I ran across an article on 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

Re: [HACKERS] generated columns

2017-10-02 Thread Adam Brusselback
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

Re: [HACKERS] Proposal: global index

2017-08-24 Thread Adam Brusselback
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.

Re: [HACKERS] PG10 transition tables, wCTEs and multiple operations on the same table

2017-06-06 Thread Adam Brusselback
> > 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

Re: [HACKERS] CTE inlining

2017-05-15 Thread Adam Brusselback
>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

Re: [HACKERS] Separate connection handling from backends

2016-12-06 Thread Adam Brusselback
> > 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

Re: [HACKERS] delta relations in AFTER triggers

2016-11-02 Thread Adam Brusselback
> > 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

Re: [HACKERS] delta relations in AFTER triggers

2016-11-02 Thread Adam Brusselback
> > 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

Re: [HACKERS] GiST support for UUIDs

2016-11-01 Thread Adam Brusselback
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

Re: [HACKERS] Indirect indexes

2016-10-21 Thread Adam Brusselback
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