Indeed... I looked through the official TODO list and was unable to
find an entry for global temporary tables- such a thing would be
ideal for any transient data such as web sessions or materialized
views. Is there any reason why global temp tables shouldn't be
implemented? (And, no, I'm no
On Apr 3, 2007, at 15:39 , C. Bergström wrote:
A.M. wrote:
Indeed... I looked through the official TODO list and was unable
to find an entry for global temporary tables- such a thing would
be ideal for any transient data such as web sessions or
materialized views. Is there any reason why
On Apr 3, 2007, at 16:00 , Alan Hodgson wrote:
On Tuesday 03 April 2007 12:47, "A.M."
<[EMAIL PROTECTED]> wrote:
On Apr 3, 2007, at 15:39 , C. Bergström wrote:
I would like to use transactional semantics over tables that can
disappear whenever the server fails. memcached doe
On Oct 7, 2007, at 9:14 , Jeffrey Brower wrote:
Greetings All,
I have to authenticate against an existing (constantly modified)
PostgreSQL
database under Solaris 10 (X86). While my PHP scripts are an obvious
no-brainer, the rest of the contents need to be protected as well
(images,
etc
On Jun 24, 2010, at 4:01 PM, Pavel Stehule wrote:
> 2010/6/24 Joshua D. Drake :
>> On Thu, 2010-06-24 at 21:14 +0200, Pavel Stehule wrote:
>>> 2010/6/24 Josh Berkus :
> And I'm also planning to implement unlogged tables, which have the
> same contents for all sessions but are not WA
On Oct 25, 2010, at 2:46 PM, Steve Wong wrote:
> Hi experts,
>
> I have a (near) real-time application in which inserts into the database
> needs
> to be visible to queries from other threads with minimal delay. The inserts
> are
> triggered by real-time events and are therefore asynchronous
Explain analyze could at least put an asterisk around actual time that
deviated by some factor from the estimated time.
On Tue, June 6, 2006 10:39 am, Simon Riggs wrote:
>
> This is a good example of a case where the inefficiency of EXPLAIN
> ANALYZE would be a contributory factor to it not actua
Hmmm...It could generate NOTICEs whenever there is a drastic difference in
rowcount or actual time...
On Tue, June 6, 2006 11:29 am, Andrew Sullivan wrote:
> On Tue, Jun 06, 2006 at 11:06:09AM -0400, Tom Lane wrote:
>
>>> it was properly instrumented. That way, the OP might have been able
>>> to d
On Wed, June 14, 2006 1:04 pm, John Vincent wrote:
> I know it is but that's what we need for some of our queries. Our ETL
> tool (informatica) and BI tool (actuate) won't let us set those things as
> part of our jobs. We need it for those purposes. We have some really nasty
> queries that will be
On Thu, July 6, 2006 1:53 pm, Merlin Moncure wrote:
> with all these unsubscribe requests, we can only extrapolate that the
> server has no serious performance issues left to solve. good work! :-)
Well, either that or the performance issues are so severe that users are
dropping like flies...
-M
On Dec 20, 2007, at 11:30 AM, Roberts, Jon wrote:
-Original Message-
From: Merlin Moncure [mailto:[EMAIL PROTECTED]
Sent: Thursday, December 20, 2007 8:30 AM
To: Roberts, Jon
Cc: Alvaro Herrera; Trevor Talbot; Joshua D. Drake; Kris Jurka;
Jonah H.
Harris; Bill Moran; pgsql-perform
On Jan 23, 2008, at 2:57 PM, Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server
will
be a better way to spend your money. For certain high throughput,
relatively smal
On Jan 27, 2012, at 2:59 PM, Carlo Stonebanks wrote:
> Was I even right in thinking I would gain any performance by converting to
> SQL?
As always, it depends. I converted an immutable pl/pgsql function to an SQL
function and the body of the function barely changed. However, I experienced an
o
13 matches
Mail list logo
