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 entirely.
How
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 comparison
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-defined
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
you
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 understanding is,
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
interface.
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 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. Note
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
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
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
CTMD Business Unit
972-52-4286-513
[EMAIL PROTECTED]
---(end of
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 materialized views
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 plan
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,
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
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
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
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
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.
--
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 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
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, 2008
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
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-vis
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 suggestion
25 matches
Mail list logo
