On Jan 3, 2008 12:44 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> > I actually mean to say that DDLs can be declared as self-committing.
>
> Egad, an Oracle lover in our midst.
:). True, its an impact of working more with Oracle. I made the
"Gokulakannan Somasundaram" <[EMAIL PROTECTED]> writes:
> I actually mean to say that DDLs can be declared as self-committing.
Egad, an Oracle lover in our midst.
Most of us think that roll-back-able DDL is one of the best features of
Postgres, and certainly one of our best selling points vis-a-v
Is there why we allow DDLs inside a transaction and allow it to be rolled
back? If we commit the previous transaction, as soon as we encounter a DDL,
and commit the DDL too (without waiting for commit) will it be affecting
some use cases?
I actually mean to say that DDLs can be declared as self-co
Thanks, I think you have me on the right track. I'm testing a vacuum
analyse now to see how long it takes, and then I'll set it up to
automatically run every night (so that it has a chance to complete
before about 6am.)
On 02/01/2008, Andrew Sullivan <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 20
On Wed, Jan 02, 2008 at 05:56:14PM +, Simon Riggs wrote:
> Like it?
Sounds good. I've only given it a quick scan though. Would read-only
segments retain the same disk-level format as is currently? It seems
possible to remove the MVCC fields and hence get more tuples per page---
whether this
Simon Riggs wrote:
On Tue, 2008-01-01 at 16:09 -0500, Tom Lane wrote:
Paranoia would
suggest forbidding *any* form of ALTER TABLE when there are pending
trigger events, but maybe that's unnecessarily strong.
That works for me. Such a combination makes no sense, so banning it is
the
On Tue, 2008-01-01 at 16:09 -0500, Tom Lane wrote:
> Paranoia would
> suggest forbidding *any* form of ALTER TABLE when there are pending
> trigger events, but maybe that's unnecessarily strong.
That works for me. Such a combination makes no sense, so banning it is
the right thing to do.
--
S
On Wed, 2008-01-02 at 09:29 -0600, Abraham, Danny wrote:
> Our product is about 20 times slower on Postgres compared to MS SQL
> Server.
If you want to have a cross-platform product then you must consider how
to access multiple systems both accurately and quickly. Not much point
catering for the
Happy New Year, everybody.
This proposal follows on from previous thinking about partitioning,
where I've taken up Andrew Sullivan's suggestion to re-examine the
current partitioning concept of using tables as partitions. So I've come
up with an alternative concept to allow us to discuss the parti
On Wed, Jan 02, 2008 at 05:53:35PM +0200, Brian Modra wrote:
> This table is added to in real time, at least 10 rows per second.
[. . .]
> If I do a select which uses the pkey index, where equal to the ID
> column, and greater than one of the values, which should return about
> 1500 rows, it some
On Wed, Jan 02, 2008 at 09:29:24AM -0600, Abraham, Danny wrote:
> We are looking for a patch that will help us count using the indexes.
Is this for
SELECT count(*) FROM table;
or
SELECT count(1) FROM table WHERE. . .
The latter _will_ use an index, if the ind
Hi,
I have a table with a primarry key made of two columns.
One of these has about 150 distinct values which are unique IDs, and
the other has over 3 million almost unique data values.
This table is added to in real time, at least 10 rows per second.
If I do a select which uses the pkey index, wh
am Wed, dem 02.01.2008, um 9:29:24 -0600 mailte Abraham, Danny folgendes:
> Hi,
>
> We are looking for a patch that will help us count using the indexes.
>
> Our product is about 20 times slower on Postgres compared to MS SQL
> Server.
>
> Any ideas?
Please show us your SQL and the execution
On 02/01/2008, Abraham, Danny <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We are looking for a patch that will help us count using the indexes.
>
> Our product is about 20 times slower on Postgres compared to MS SQL
> Server.
>
> Any ideas?
There isn't any similar patch and will not be.
Use materialize
Hi,
We are looking for a patch that will help us count using the indexes.
Our product is about 20 times slower on Postgres compared to MS SQL
Server.
Any ideas?
Danny Abraham
BMC Software
CTM&D Business Unit
972-52-4286-513
[EMAIL PROTECTED]
---(end of broadcast)-
OK, so i was going through the autovacuum code and i noticed that when we
construct the table list to vacuum in a database per run, we don't process
them in a particular order. I mean since we pick the list up from pg_class
so it may be ordered on oid? but when we select a database we have a
priori
On Wed, Jan 02, 2008 at 01:17:03PM +, Simon Riggs wrote:
> That's right; shame I forgot this before I started the thread...
Actually, I think your idea has merit, it's just not as easy as
originally thought. All splits, including multiple-level splits, can be
described as a sequence of "split
On Jan 2, 2008 6:24 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 02, 2008 at 04:46:11PM +0530, Gokulakannan Somasundaram wrote:
> > > All indexes are done by user-defined functions, even b-trees. People
> can
> > > make their own b-tree indexes by defining an operator class.
On Wed, 2008-01-02 at 13:54 +0100, Martijn van Oosterhout wrote:
> On Wed, Jan 02, 2008 at 04:46:11PM +0530, Gokulakannan Somasundaram wrote:
> > > All indexes are done by user-defined functions, even b-trees. People can
> > > make their own b-tree indexes by defining an operator class. Note that
>
On Wed, Jan 02, 2008 at 04:46:11PM +0530, Gokulakannan Somasundaram wrote:
> > All indexes are done by user-defined functions, even b-trees. People can
> > make their own b-tree indexes by defining an operator class. Note that
> > "user-defined" is this case means anything called via the fmgr
> > i
>
>
> All indexes are done by user-defined functions, even b-trees. People can
> make their own b-tree indexes by defining an operator class. Note that
> "user-defined" is this case means anything called via the fmgr
> interface.
Again, i think i have one more wrong understanding. My understandin
On Wed, Jan 02, 2008 at 04:04:48PM +0530, Gokulakannan Somasundaram wrote:
> On Jan 2, 2008 3:35 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> > If the goal is to only store the insert, then we need to determine
> > during recovery which page the record needs to be added to. To do this
>
On Jan 2, 2008 3:35 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>
> If the goal is to only store the insert, then we need to determine
> during recovery which page the record needs to be added to. To do this
> you need to go through the index, which can only be done by calling
> user-def
On Wed, Jan 02, 2008 at 02:49:35PM +0530, Gokulakannan Somasundaram wrote:
> On Jan 2, 2008 2:25 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> > On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
> > > How are you going to avoid the need to run user-defined functions
> > > (specifically, the btree c
On Jan 2, 2008 2:25 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-01 at 14:02 -0500, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > If we could log *only* the insert that caused the split, rather than
> the
> > > split itself, we would avoid that situation entirel
25 matches
Mail list logo
