Hi,
[ remembering previous discussions more clearly... ] Actually there
is a concrete problem here: unique constraints are supposed to be
represented in the information_schema views, and there is no
spec-compliant way to do that for a constraint on something other than
a column. We'd have to
CK Tan wrote:
If it is convenient for you, could you run my patch against the same
hardware and data to get some numbers on select for comparison? Although
we don't address updates, copy, or inserts, we are definitely getting
at least 20% improvement in scans here without poisoning the bufpool
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
scrollable. So maybe I should put an explicit check during cursor
creation disallowing scrollable updateable cursors.
Rgds,
Arul Shaji
Pavel Stehule wro
Alvaro Herrera wrote:
While we're at this, let's consider Heikki's patch for the streaming
indexscan API stuff. That patch was supposed to come from the bitmap
index patch, but it was also supposed to help the Grouped Index Tuples
(GIT) patch.
In fact, as far as I understood the discussion, GIT
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
In any case, I do want this for VACUUMs to fix the "WAL flush for every
dirty page" problem. Maybe we should indeed drop the other aspects of
the patch and move on, I'm getting tired of this as well.
Can we devise a small patch th
Correction Meant to say
According to the standard, updateable cursors cannot be scrollable until
we have full cursor update.
FAST PostgreSQL wrote:
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
Jaime Casanova wrote:
On 5/16/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Jim C. Nasby wrote:
> What about adding the ability to ask the FSM for a page that's near a
> given page? That way if you did have to go to the FSM you could at
least
> try and insert close to the page you original
Pavan Deolasee wrote:
--- 1179,1189
dbname, user, password);
/* We can immediately discard the password -- no longer needed */
! if (password)
! {
! memset(password, '\0', strlen(password));
free(password);
+ }
Any
Hi Greg,
I looked at the patch briefly. I couldn't spot any issues and it looks good
to me. I've just couple of comments here.
The mvcc regression test files are missing in the patch.
--- 1179,1189
dbname, user, password);
/* We can immediately discard
2007/5/18, FAST PostgreSQL <[EMAIL PROTECTED]>:
Right. The current implementation allows only simple queries. Joins are
disallowed. According to the standard, updateable cursors cannot be
scrollable. So maybe I should put an explicit check during cursor
creation disallowing scrollable updateable
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
He
NikhilS <[EMAIL PROTECTED]> writes:
>> [ remembering previous discussions more clearly... ] Actually there
>> is a concrete problem here: unique constraints are supposed to be
>> represented in the information_schema views, and there is no
>> spec-compliant way to do that for a constraint on somet
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
The beef of the patch is two new optional indexam API functions:
amprepareinsert and amfinishinsert. amprepareinsert is called before
inserting the heap tuple. It descends the tree and finds and pins the
right leaf page to insert t
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> The beef of the patch is two new optional indexam API functions:
> amprepareinsert and amfinishinsert. amprepareinsert is called before
> inserting the heap tuple. It descends the tree and finds and pins the
> right leaf page to insert to, and ret
Tom Lane wrote:
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
Yes, I only used the 'disjoint representations for first-bytes and
not-first-bytes of MB characters' feature in UTF8. Other encodings
allows both [AB] and [BA] for MB character patterns. UTF8Match() does
not cope with those encodi
Hi,
here's a fix for a _very_ longstanding bug in PostgreSQL.
According to SQL:2003 DEFAULT may only contain
certain functional expressions and constant literals.
Please, note the year of the standard. Or I know a better one,
PostgreSQL is not even SQL92 compliant in this regard, after 14 years!
Zoltan Boszormenyi wrote:
Hi,
here's a fix for a _very_ longstanding bug in PostgreSQL.
According to SQL:2003 DEFAULT may only contain
certain functional expressions and constant literals.
Please, note the year of the standard. Or I know a better one,
PostgreSQL is not even SQL92 compliant in t
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Or not, it's just a bitter and late (because of my bitterness) response
> to the rejection of my IDENTITY/GENERATED patches.
> Where's the much praised standard behaviour on standard syntax?
> So much for hypocrisy.
Hm? There's a difference between
On 5/18/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Jaime Casanova wrote:
>
> the patch doesn't apply in cvs... you'll need to update it...
Oh, here you are.
The implementation has changed a bit since August. I thought I had
submitted an updated version in the winter but couldn't find it.
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Or not, it's just a bitter and late (because of my bitterness) response
to the rejection of my IDENTITY/GENERATED patches.
Where's the much praised standard behaviour on standard syntax?
So much for hypocrisy.
Hm? There's a
20 matches
Mail list logo
