Hi,
I have given some thought in this direction. I am just providing my idea.
a) Have a structure similar to commit log, which should also store,
transaction id at which the transaction got committed. Every transaction,
after committing should update the transaction id at which the commit has
h
Andrew Dunstan writes:
> Jean-Michel Pouré wrote:
>> Why can't PostgreSQL add the required field automatically? Could this be
>> added to PostgreSQL to-do-list?
> Isn't that contrary to the standard?
As of SQL99 it's supposed to be legal if you're grouping by a primary key
(or some other cases w
Greg Stark wrote:
If Postgres changed on this front it would be to support the SQL
Standard concept of "functional dependency". In cases where some
columns are guaranteed to be unique you can leave them out of the
GROUP BY but still use them in the select list. This isn't MySQL's
behaviour of j
On Friday 21 August 2009 04:01:36 pm Andrew Dunstan wrote:
> Jean-Michel Pouré wrote:
> >> BTW, why don't we have a multi-argument version of CONCAT()? In 8.4,
> >> it
> >> would be possible ... I should add it to mysqlcompat library.
> >
> > yes. In PostgreSQL core ...
>
> No. That is exactly wh
Greg Stark writes:
> The first step is probably to do the opposite of what we're talking
> about here: cases where people *have* added extra columns to the GROUP
> BY key so they can use those columns in their select list. We can
> remove those columns from the sort or hash comparison key if there
2009/8/22 Stephen Frost :
>> This is a bit trickier than it looks because it makes the validity of a
>> query dependent on the existence of an appropriate uniqueness
>> constraint; thus for example DROP CONSTRAINT might invalidate a stored
>> rule or view. See prior discussions.
>
> Ah, yes. Coul
* Greg Stark (gsst...@mit.edu) wrote:
> So not many uses of it in MySQL actually *would* be valid if we
> implemented the shortcut. But MySQL doesn't enforce that so it serves
> that purpose as well as what we get out of DISTINCT ON.
That's probably a good thing- if they're valid then we'd probabl
2009/8/22 Stephen Frost :
> * Greg Stark (gsst...@mit.edu) wrote:
>> You would have to specify the key. I think typically you would have
>> something like:
>>
>> SELECT a.*, sum(b.col)
>> FROM a,b
>> GROUP BY a.pk
>
> Ahhh, ok, this makes more sense. This is SQL standard?
Incidentally it make
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Right. It strikes me as a relativly small amount of work to get the
> > initial "just add the columns to the group by" logic implemented.
>
> Well, no, you *aren't* adding the columns to the GROUP BY. You're just
> not throwing
Stephen Frost writes:
> Right. It strikes me as a relativly small amount of work to get the
> initial "just add the columns to the group by" logic implemented.
Well, no, you *aren't* adding the columns to the GROUP BY. You're just
not throwing the error. You really don't want to add redundant
Ron Mayer wrote:
> Robert Haas wrote:
> > On Wed, Jul 22, 2009 at 2:17 PM, Andrew
> > Gierth wrote:
> >> Unless I hear any objections I will proceed accordingly...
> >
> > At this point it's been 12 days since this was written and no updated
> > patch has been posted, so I think it's well past tim
* Greg Stark (gsst...@mit.edu) wrote:
> You would have to specify the key. I think typically you would have
> something like:
>
> SELECT a.*, sum(b.col)
>FROM a,b
> GROUP BY a.pk
Ahhh, ok, this makes more sense. This is SQL standard? Do we have a
TODO for it?
> The database knows that it
2009/8/22 Stephen Frost :
> Hrmm. That sounds kinda neat, but you'd still have to specify one of
> the columns in the GROUP BY, I presume? Or could you just say 'GROUP
> BY' without any columns, and have it GROUP BY the key of the table
> you're using?
You would have to specify the key. I think
On Sat, Aug 22, 2009 at 1:37 AM, Tom Lane wrote:
> You can see that from the fact that the estimated row width is
> 8 bytes (two integers) ... but tenthous is nowhere to be seen in the
> Output: line.
+1 for self-consistent output. If we're including their size in
"width" then they should be in th
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Currently, explain.c goes out of its way to not print "resjunk" output
> columns (those not meant to be seen by the user, such as hidden sort key
> columns) in EXPLAIN VERBOSE targetlists. I made 8.4 act that way for
> reasons I don't recall at the moment,
* Greg Stark (gsst...@mit.edu) wrote:
> select distinct on (a) a,b,c from a ORDER BY a,b,c
>
> But Postgres insists you have an ORDER BY which has to agree with the
> DISTINCT ON columns and provide some extra column(s) to determine
> which values of b,c are chosen.
Not quite technically correct.
Robert Haas wrote:
> On Wed, Jul 22, 2009 at 2:17 PM, Andrew
> Gierth wrote:
>> Unless I hear any objections I will proceed accordingly...
>
> At this point it's been 12 days since this was written and no updated
> patch has been posted, so I think it's well past time to move this to
> "Returned w
Currently, explain.c goes out of its way to not print "resjunk" output
columns (those not meant to be seen by the user, such as hidden sort key
columns) in EXPLAIN VERBOSE targetlists. I made 8.4 act that way for
reasons I don't recall at the moment, but I've found several times now
that it's misl
2009/8/21 Jean-Michel Pouré :
> PostgreSQL requires all non-aggregated fields to be present in the GROUP
> BY clause (I fixed 10 such issues in Drupal code).
> http://drupal.org/node/30
>
> Why can't PostgreSQL add the required field automatically? Could this be
> added to PostgreSQL to-do-list
Jean-Michel Pouré wrote:
BTW, why don't we have a multi-argument version of CONCAT()? In 8.4,
it
would be possible ... I should add it to mysqlcompat library.
yes. In PostgreSQL core ...
No. That is exactly where it shouldn't go. And frankly, Drupal
developers should stop writ
Tom Lane napsal(a):
Petr Jelinek writes:
However there is one question about implementing it in plpgsql.
Currently, the compiler reads info directly from heap tuple, so I either
have to write separate compiler for inline functions or change the
existing one to accept the required info as p
On 8/21/09 3:17 PM, Tom Lane wrote:
> David Fetter writes:
>> On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
>>> Josh Berkus writes:
BTW, why don't we have a multi-argument version of CONCAT()?
>>> Why wouldn't people use the SQL-standard || operator instead?
>
>> Because by defa
David Fetter writes:
> On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
>> Josh Berkus writes:
>>> BTW, why don't we have a multi-argument version of CONCAT()?
>>
>> Why wouldn't people use the SQL-standard || operator instead?
> Because by default, MySQL uses that as, get this, "logic
On Fri, Aug 21, 2009 at 04:19:43PM -0400, Tom Lane wrote:
> Josh Berkus writes:
> > BTW, why don't we have a multi-argument version of CONCAT()?
>
> Why wouldn't people use the SQL-standard || operator instead?
Because by default, MySQL uses that as, get this, "logical OR."
Cheers,
David (grate
Petr Jelinek writes:
> However there is one question about implementing it in plpgsql.
> Currently, the compiler reads info directly from heap tuple, so I either
> have to write separate compiler for inline functions or change the
> existing one to accept the required info as parameters and "fa
Alvaro Herrera writes:
> Tom Lane wrote:
>> I'd still like to have some fork-rate-limiting behavior in there
>> somewhere. However, it might make sense for the avlauncher to do that
>> rather than the postmaster. Does that idea seem more implementable?
> Well, there's already rate limiting in t
Tom Lane napsal(a):
That's really ugly. It'll cause catalog bloat with every execution.
I think it would be acceptable to have a new column in pg_language that
pointed to an anonymous block execute function. Languages that do not
define this function cannot use this new feature.
+1. The
Tom Lane wrote:
> I'd still like to have some fork-rate-limiting behavior in there
> somewhere. However, it might make sense for the avlauncher to do that
> rather than the postmaster. Does that idea seem more implementable?
Well, there's already rate limiting in the launcher:
Alvaro Herrera writes:
> Tom Lane wrote:
>> It does seem that we ought to change things so that there's a bit more
>> delay before trying to re-launch a failed autovac worker, though.
>> Whatever caused this was effectively turning the autovac logic into
>> a fork-bomb engine. I'm not thinking of
> I've registered for the Drupal site so that I can fix and/or expand
> some
> of your items.
Thanks. I corrected the index on dual fields page.
> If you want to discuss Drupal & PostgreSQL again, please post on the
> pgsql-advocacy list or the pgsql-php mailing lists. pgsql-hackers
> isn't
> th
Tom Lane wrote:
> Alvaro Herrera writes:
> > If sigusr1_handler needs rewriting, don't all the other sighandler as
> > well?
>
> It does not, and neither do they. I'm not sure what happened here but
> it wasn't the fault of the postmaster's organization of signal handlers.
>
> It does seem that
Josh Berkus writes:
> BTW, why don't we have a multi-argument version of CONCAT()?
Why wouldn't people use the SQL-standard || operator instead?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Alvaro Herrera writes:
> If sigusr1_handler needs rewriting, don't all the other sighandler as
> well?
It does not, and neither do they. I'm not sure what happened here but
it wasn't the fault of the postmaster's organization of signal handlers.
It does seem that we ought to change things so th
Alvaro Herrera píše v pá 21. 08. 2009 v 15:40 -0400:
> Zdenek Kotala wrote:
>
> > The problem what I see here is that StartAutovacuumWorker() fails and
> > send SIGUSR1 to the postmaster, but it send it too quickly and signal
> > handler is still active. When signal mask is unblocked in
> > sigus
Zdenek Kotala wrote:
> The problem what I see here is that StartAutovacuumWorker() fails and
> send SIGUSR1 to the postmaster, but it send it too quickly and signal
> handler is still active. When signal mask is unblocked in
> sigusr1_handler() than signal handler is run again...
>
> The reason w
Jean-Michel,
Thank you for doing this!
I've registered for the Drupal site so that I can fix and/or expand some
of your items.
People who know Drupal better than me should add to them.
If you want to discuss Drupal & PostgreSQL again, please post on the
pgsql-advocacy list or the pgsql-php mail
Thought another message might be appropriate as I've made some
progress: finished up PEP302 interfaces on PyPgFunction
objects(provides linecache support for tracebacks), IST support, DB
error handling(pg error -> pyexc -> pg error), and, recently, some
annoying type interface improvements.
On 18 August 2009 at 16:18 Tom Lane wrote:
> Simon, this concept is completely broken, as far as I can tell.
Thanks for the precise example.
Yes, I agree it is not going to work when there could be more than one row
version in the relation. Which doesn't leave useful wriggle room, so not
pu
On 19 August 2009 at 00:09 Josh Berkus wrote:
> When we discussed Hot Standby at pgCon 2008, we discussed the
> possibility of stopping the replications stream whenever a VACUUM came
> through until any queries currently running on the slave completed. Did
> that approach turn out to be comple
On 21 August 2009 at 10:18 Jeff Janes wrote:
> The effect of this seems to be that when WALInsertLock is busy, group
> commits are suppressed.
Agreed, but its not a place to look at just yet since this is changing as part
of sync rep patch.
We do need to change this to make group commit work
On Aug 20, 2009, at 11:18 PM, Josh Berkus wrote:
I don't think it's a bad idea, I just think you have to set your
expectations pretty low. If the estimates are bad there isn't really
any plan that will be guaranteed to run quickly.
Well, the way to do this is via a risk-confidence system. That
2009/8/21 Jean-Michel Pouré :
> Dear friends,
>
> I have been using PostgreSQL since 6.3 releases and I am a real fan.
> Of course, I never use nor trust MySQL to deliver data.
>
> Now I use Drupal 6.3 with PostgreSQL 8.4.
>
> I loose a lot of time correcting Drupal SQL.
> You may be interested in
On Fri, Aug 21, 2009 at 7:27 AM, Heikki
Linnakangas wrote:
> Greg Stark wrote:
>> It looks like right now if an indexam has amregurgitate
>> set but not amhasgettuple then weird things could happen.
>
> The combination (amregurgitate && !amhasgettuple) makes no sense, BTW.
> If an indexam has no ge
Greg Stark wrote:
2009/8/21 Andrew Dunstan :
Since you haven't shown us what page this refers to, I at least am totally
in the dark about what is being discussed.
It was in the original post
http://drupal.org/node/14
Darn. Our mail system sucks badly. For some insane reaso
2009/8/21 Andrew Dunstan :
>
> Since you haven't shown us what page this refers to, I at least am totally
> in the dark about what is being discussed.
It was in the original post
http://drupal.org/node/14
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-hackers mailing list (p
Joshua D. Drake wrote:
This page gathers most frequent problems that Drupal users and
developers encounter when using PostgreSQL.
I would be delighted to have your feedback.
Could some issues reasonably be fixed for a better Drupal support?
Well I doubt we would do anything to copy MySQ
On Fri, 2009-08-21 at 12:50 -0400, Bruce Momjian wrote:
> I show multi-value INSERT was added in PG 8.2, not 8.4, * Add
> support for multiple-row VALUES clauses, per SQL standard (Joe, Tom),
> http://drupal.org/node/68.
>
> I am confused because I thought Drupal worked with Postgres, bu
Jean-Michel Pour? wrote:
-- Start of PGP signed section.
> Dear friends,
>
> I have been using PostgreSQL since 6.3 releases and I am a real fan.
> Of course, I never use nor trust MySQL to deliver data.
>
> Now I use Drupal 6.3 with PostgreSQL 8.4.
>
> I loose a lot of time correcting Drupal
On Fri, 21 Aug 2009 18:22:41 +0200
Jean-Michel Pouré wrote:
> I gathered some real examples here: Guidelines for writing MySQL and
> PostgreSQL compliant SQL => http://drupal.org/node/14
>
> This page gathers most frequent problems that Drupal users and
> developers encounter when using Postg
> This page gathers most frequent problems that Drupal users and
> developers encounter when using PostgreSQL.
>
> I would be delighted to have your feedback.
> Could some issues reasonably be fixed for a better Drupal support?
Well I doubt we would do anything to copy MySQL. However Drupal has
Dear friends,
I have been using PostgreSQL since 6.3 releases and I am a real fan.
Of course, I never use nor trust MySQL to deliver data.
Now I use Drupal 6.3 with PostgreSQL 8.4.
I loose a lot of time correcting Drupal SQL.
You may be interested in my developer feedback.
I gathered some rea
Alvaro Herrera writes:
> So is this the right way to approach the problem, or am I missing some
> simpler way?
See discussions of NikhilS's patch last year. I think the conclusion we
had arrived at was that we should refactor the representation of SubLink
so that a single-row subselect could be
Martijn van Oosterhout writes:
> If you want index support, you need to go the whole way, and setup an
> appropriate operator class for (box,point).
No, I think he's doing the right thing by adding these cross-type
operators "loose" in the opfamily. An operator class is the subset
of an opfamily
Alvaro Herrera writes:
> Petr Jelinek wrote:
>> The implementation as I see it would create function in pg_temp
>> namespace, call it and then drop it. Any other implementation would
>> imho mean rewriting procedure language api.
> That's really ugly. It'll cause catalog bloat with every executi
Jeff Janes writes:
> Maybe this is one of those things that is obvious when someone points
> it out to you, but right now I am not seeing it. If you look at the
> last eight lines of this snippet from XLogFlush, you see that if we
> obtain WriteRqstPtr under the WALInsertLock, then we both write
On Fri, Aug 21, 2009 at 09:42:57PM +1000, Paul Matthews wrote:
> Martijn van Oosterhout wrote:
> > I haven't completely understood what you're trying to do
> >
> Putting in place the missing 'box op point' and 'point op box'
> operators. The problematic queries are at the bottom of the email.
I
Paul Matthews writes:
> The C function? No it seems OK as well. What am I missing?
Did you teach the opclass's consistent() function about these new
operators?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
Alvaro Herrera writes:
> NOTICEs is what we do with index creation on primary key, unique
> indexes, and sequences on serial columns, and I think they are seen as
> just noise by everyone except novices. Do we want to add more?
> Maybe they should be INFO, so that they are shown to the client bu
I found following core file of PG 8.4.0 on my system (Solaris Nevada
b119):
fe8ae42d _dowrite (85bf6e8, 3a, 8035e3c, 80350e8) + 8d
fe8ae743 _ndoprnt (85bf6e8, 8035ec8, 8035e3c, 0) + 2ba
fe8b322d vsnprintf (85bfaf0, 3ff, 85bf6e8, 8035ec8, 0, 0) + 65
082194ea appendStringInfoVA (8035e9c, 85bf6e8
Brendan Jurd escribió:
> I would be fine with a NOTICE in the former case, so something like
> this would be cool
>
> # CREATE TABLE foo (LIKE bar INCLUDING INDEXES);
> NOTICE: INCLUDING INDEXES will also include any constraints on those indexes.
> HINT: Specify EXCLUDING CONSTRAINTS to omit them
Greg Stark wrote:
> It looks like right now if an indexam has amregurgitate
> set but not amhasgettuple then weird things could happen.
The combination (amregurgitate && !amhasgettuple) makes no sense, BTW.
If an indexam has no gettuple function, there's no way it can return
data from the index.
Greg Stark wrote:
> On Fri, Aug 21, 2009 at 12:43 PM, Heikki
> Linnakangas wrote:
>> Here is an updated version of my patch to return data from b-tree
>> indexes, and use it to satisfy quals.
>
> + if (!found_clause && useful_pathkeys == NIL &&
> !useful_predicate)
> +
On Fri, Aug 21, 2009 at 12:43 PM, Heikki
Linnakangas wrote:
> Here is an updated version of my patch to return data from b-tree
> indexes, and use it to satisfy quals.
+ if (!found_clause && useful_pathkeys == NIL &&
!useful_predicate)
+ ipath->
On Fri, Aug 21, 2009 at 12:43 PM, Heikki
Linnakangas wrote:
>
> I added a new column 'amregurgitate' to pg_am, to mark which indexams
> can return index tuples.
Very picturesque but uh, perhaps the more mundane "amcanrettuples"
would be clearer?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Se
Martijn van Oosterhout wrote:
> I haven't completely understood what you're trying to do
>
Putting in place the missing 'box op point' and 'point op box'
operators. The problematic queries are at the bottom of the email.
> - I don't see any definition of an operator class, just the family,
> w
Hi,
Le 21 août 09 à 06:04, Jeff Davis a écrit :
There is not much of a problem with backwards compatibility. LIKE is
shorthand (not stored in catalogs), so it doesn't affect
pg_dump/restore. And hopefully there aren't a lot of apps out there
creating tables dynamically using the LIKE syntax.
I
On Fri, Aug 21, 2009 at 08:28:05PM +1000, Paul Matthews wrote:
> Trying to solve this problem by using a process of elimination. All
> works fine until the comment below is removed.
I haven't completely understood what you're trying to do, but I have a
few points.
- I don't see any definition of
Trying to solve this problem by using a process of elimination. All
works fine until the comment below is removed.
ALTER OPERATOR FAMILY box_ops USING GiST ADD
OPERATOR 1 << (box,point),
OPERATOR 2 &< (box,point),
OPERATOR 3 && (box,point),
OPERATOR 4 &> (box,point),
OPERATOR 5
Maybe this is one of those things that is obvious when someone points
it out to you, but right now I am not seeing it. If you look at the
last eight lines of this snippet from XLogFlush, you see that if we
obtain WriteRqstPtr under the WALInsertLock, then we both write and
flush up to the highest
69 matches
Mail list logo
