PMFJI
> We seem to have a few options for PG11
>
> 1. Do nothing, we reject MERGE
>
> 2. Implement MERGE for unique index situations only, attempting to
> avoid errors (Simon OP)
>
> 3. Implement MERGE, but without attempting to avoid concurrent ERRORs
> (Peter)
>
> 4. Implement MERGE, while
akapila wrote:
> You might want to give a try with the hash index if you are planning
> to use PG10 and your queries involve equality operations.
But you can't replace the PK index with a hash index, because hash indexes
don't support uniqueness.
--
Sent from:
> Just to se what other RDBMS are doing with CTEs; Look at slide
> 31 here:
> https://www.percona.com/live/17/sites/default/files/slides/Recursive%20Query%20Throwdown.pdf
That is taken from Markus Winand's post:
https://twitter.com/MarkusWinand/status/852862475699707904
"Seems like MySQL
> 1) we switch unmarked CTEs as inlineable by default in pg11.
+1 from me for option 1
--
View this message in context:
http://www.postgresql-archive.org/CTE-inlining-tp5958992p5959615.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers
> I could tolerate telling people to use OFFSET 0 (and documenting it!)
> as a workaround if we can't get something more friendly in.
I agree with that.
> If we go with WITH INLINE then we're likely not solving anything, because
> most people will simply use WITH just like now, and will be
> Relevant posts where users get confused by our behaviour:
>
And Markus Winand's blog: http://modern-sql.com/feature/with/performance
Databases generally obey this principle, although PostgreSQL represents
a big exception
and
Besides PostgreSQL, all tested databases optimize
Greg Stark wrote
> I don't think this even needs to be tied to currencies. I've often
> thought this would be generally useful for any value with units. This
> would prevent you from accidentally adding miles to kilometers or
> hours to parsecs which is just as valid as preventing you from adding
Wolfgang Wilhelm wrote
> - The more difficult a database change including rewriting of code will
> get the less likely you'll find something paying for it. In my case there
> is a list of reasons from the customer _not_ to switch from Oracle to
> PostgreSQL. Besides more obvious reasons like APEX
> FWIW, while this is basically true, the idea of repurposing UNDO to be
> usable for MVCC is definitely an Oracleism. Mohan's ARIES paper says
> nothing about MVCC.
> For snapshot isolation Oracle has yet a *third* copy of the data in a
> space called the "rollback segment(s)".
UNDO and
Pavel Stehule wrote
> Session server side variables are one major missing feature in PLpgSQL.
I think this would also be useful outside of PL/pgSQL to support query level
variables similar to what SQL Server does.
--
View this message in context:
Masahiko Sawada schrieb am 30.09.2016 um 12:54:
I did this on two different computers, one with Windows 10 the other with
Windows 7.
(only test-databases, so no real issue anyway)
In both cases running a "vacuum full" for the table in question fixed the
problem and pg_upgrade finished without
Tom Lane-2 wrote
> The problem with an extension is: when we make a core change that breaks
> one of these views, which we will, how can you pg_upgrade a database
> with the extension installed? There's no provision for upgrading an
> extension concurrently with the core upgrade. Maybe there
Oleg Bartunov-2 wrote
> But still, icu provides us abbreviated keys and collation stability,
Does include ICU mean that collation handling is identical across platforms?
E.g. a query on Linux involving string comparison would yield the same
result on MacOS and Windows?
If that is the case I'm
Robert Haas wrote:
> This isn't the first complaint about this mechanism that we've gotten,
> and it won't be the last. Way too many of our users are way more
> aware than they should be that the threshold here is five rather than
> any other number, which to me is a clear-cut sign that this
> And email integration for Jira is nonexistant.
That is not true. We do have an email integration where customers can create
issues by sending an email to a specific "Jira Email" address. And as far as
I know this is a standard module from Atlassian. I _think_ it can also be
configured that you
> We have to use something OSS; open source projects depending on
> closed-source infra is bad news. Out of what's available, I'd actually
> choose Bugzilla; as much as BZ frustrates the heck out of me at times,
> it's the only OSS tracker that's at all sophisticated.
There are several OSS
Does someone know what other DBMSs do in this regard? I.e., do they
put anything in INFORMATION_SCHEMA.VIEWS for matviews? What TABLE_TYPE
do they use in INFORMATION_SCHEMA.TABLES?
I can only speak for Oracle.
Oracle doesn't have INFORMATION_SCHEMA but their JDBC driver treats mviews
as
Possibly stopping at the tablespace level might be more straightforward.
To avoid messing up the pages in shared buffers we'd perhaps need
something like several shared buffer pools - each with either its own
blocksize or associated with a (set of) tablespace(s).
This is exactly how Oracle
Dave Page, 30.03.2009 14:28:
On Mon, Mar 30, 2009 at 1:06 PM, Thomas Kellerer spam_ea...@gmx.net wrote:
OK, thanks. I received very strange error messages last week when I accessed
that page. (Velocity Template not found and similar errors). But now it's
working.
Yeah, we had a big website
19 matches
Mail list logo
