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
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 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 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
>
>
>
> 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: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
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.
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
priori
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)-
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
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
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
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
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
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, 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.
--
S
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, 20
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
"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
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
25 matches
Mail list logo
