On Jan 14, 2011, at 5:54 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> So some questions:
>
>> * Is something seriously wrong with GiST index creation on integer[] columns?
>
>> * Why does GIN performance appear to be no better than table scans on
>> integer[] columns?
>
>> * Why does i
Kevin Grittner wrote:
I guess a manual override doesn't bother me too much, but I am a bit dubious of
its
value, and there is value in keeping the GUC count down...
It's a risk-reward thing really. The reward for removing it is that a
few lines of code and a small section of the documentatio
Tom Lane wrote:
I think we need to keep the override capability until the autotune
algorithm has proven itself in the field for a couple of years.
I agree with Josh that a negative value should be used to select the
autotune method.
Agreed on both fronts. Attached patch does the magic. Al
Here's v2 based on your feedback.
I pruned test coverage down to just the highlights. By the end of patch series,
the net change becomes +67 to alter_table.sql and +111 to alter_table.out. The
alter_table.out delta is larger in this patch (+150), because the optimizations
don't yet apply and mor
On Tue, Dec 7, 2010 at 07:24, Tim Bunce wrote:
> Changes:
>
> Sets the local $_TD via C instead of passing an extra argument.
> So functions no longer start with "our $_TD; local $_TD = shift;"
>
> Pre-extend stack for trigger arguments for slight performance gain.
>
> Passes installcheck
Stephen Frost writes:
> Okay, next user-interface question- thoughts on handling SIGHUP? My
> first reaction is that we should create a new log file on SIGHUP (if we
> don't already, havn't checked), or maybe just on SIGHUP if this variable
> changes.
> Point being, until we get Andrew's jagged-
Stephen Frost writes:
> I'd been puzzling over how to deal with this big list of fields in
> postgresql.conf and I do like the idea of some kind of short-cut being
> provided to ease the pain for users.
Yeah, I agree with the worry that a default value that's a mile long
is going to be a bit of a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah, an array or list of integer codes was what I was thinking too.
Hm, yeah, a list of integer codes might be even better/simpler.
Okay, next user-interface question- thoughts on handling SIGHUP? My
first reaction is that we should create a new log file
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> everything that looks at this GUC value
> will know instantly what it is for each version.
> The last bit is kind of a killer for tools like pgfouine, no?
Ugh.. Could we just accept it as input but return the full list if
asked for it>
> In any case I tho
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> In any case, if the GUC representation is a list of field names, I think
>> the POLA demands that the system honor the list order.
> Agreed. That puts us back into the question of how to make it
> efficient. My best thought at
Hello Joachim,
I'm reviewing this patch for CommitFest 2011-01.
On Fri, Jan 07, 2011 at 06:41:38AM -0500, Joachim Wieland wrote:
> On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland wrote:
> > What I am proposing now is the following:
> >
> > We return snapshot information as a chunk of data to th
Andrew Dunstan writes:
> The only thing I'd suggest extra is that we might allow "version_n_m" as
> shorthand for the default table layout from the relevant version.
Mmm ... seems like that just complicates matters. To make that useful,
you have to assume that there *is* a default table layout,
* Andrew Dunstan (and...@dunslane.net) wrote:
> The only thing I'd suggest extra is that we might allow
> "version_n_m" as shorthand for the default table layout from the
> relevant version.
I like that idea, makes the default a lot simpler to deal with too. :)
Thanks!
St
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> In any case, if the GUC representation is a list of field names, I think
> the POLA demands that the system honor the list order.
Agreed. That puts us back into the question of how to make it
efficient. My best thought at the moment, which doesn't strik
On 01/14/2011 09:51 PM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A user-settable column list seems pretty on-target
for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to contr
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> A user-settable column list seems pretty on-target
>> for solving those problems to me.
> I'm looking into implementing this.
> An interesting initial question is- should the users be able to control
> the *order* of the columns?
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> A user-settable column list seems pretty on-target
> for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to control
the *order* of the columns? My gut feeling, if we're giving
Robert Haas writes:
> On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane wrote:
>> I was thinking of it as being strictly a field list.
> I think we're in the process of designing a manned mission to Mars to
> solve the problem that our shoelaces are untied.
How so? ISTM the problems at hand are (a) we
On 01/14/2011 08:41 PM, Robert Haas wrote:
I think we're in the process of designing a manned mission to Mars to
solve the problem that our shoelaces are untied.
What's your suggestion, then?
cheers
andre
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I was thinking of it as being strictly a field list. I don't know
>> whether it's really practical to borrow log_line_prefix's one-character
>> names for the fields (for one thing, there would need to be names for
>> all the existi
"David E. Wheeler" writes:
> So some questions:
> * Is something seriously wrong with GiST index creation on integer[] columns?
> * Why does GIN performance appear to be no better than table scans on
> integer[] columns?
> * Why does it take 3-4x longer to create the GIN than the GiST index on
On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira
wrote:
>
> OK. I will review your patch at the beginning of the week.
>
thanks
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-h
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andrew Dunstan writes:
> > If you have a format string, what do you want to do with the bits of the
> > format that aren't field references?
>
> I was thinking of it as being strictly a field list. I don't know
> whether it's really practical to borrow l
On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 01/14/2011 05:08 PM, Tom Lane wrote:
>>> It actually sounded like a pretty good idea to me.
>
>> If you have a format string, what do you want to do with the bits of the
>> format that aren't field references?
>
> I w
Em 14-01-2011 19:50, Jaime Casanova escreveu:
On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira
wrote:
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements "named restore points".
Nice feature. I only read the provided documentation and it seems
inconsiste
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
>>> Well, actually, I just committed it. If you want to test, feel free.
>>> Note that right now only the anyarray && <@ @> operators are genuinely
>>> fixed ... I plan to hack
Em 14-01-2011 20:47, Robert Haas escreveu:
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentraut wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no substantial changes.
I'm going to st
On 1/14/11 11:51 AM, Tom Lane wrote:
> The people whose tables are mostly insert-only complain about it, but
> that's not the majority of our userbase IMO. We just happen to have a
> couple of particularly vocal ones, like Berkus.
It might or might not be the majority, but it's an extremely commo
On Fri, 2011-01-14 at 17:34 -0500, Tom Lane wrote:
>
> > I'm not keen to explain to people how we broke their applications
> just
> > because we wanted to add new functionality AND avoid one
> shift/reduce
> > conflict in our SQL grammar. Avoiding changes to user code isn't
> third
> > on that lis
On Fri, 2011-01-14 at 17:18 -0500, Tom Lane wrote:
> Jaime Casanova writes:
> > Here is a patch that implements "named restore points".
>
> > It allows DBAs to specify an exact point to which they can recover
> > but that point will have a name, so they have a better control of when
> > they wan
Robert Haas writes:
> Me, too. But I don't agree with your particular choice of small
> syntax adjustment. Maybe we should just let the issue drop for now.
> Nobody's actually complained about this that I can recall; it's just a
> comment that's been sitting there in pg_dump for ages, and I was
Andrew Dunstan writes:
> On 01/14/2011 05:08 PM, Tom Lane wrote:
>> It actually sounded like a pretty good idea to me.
> If you have a format string, what do you want to do with the bits of the
> format that aren't field references?
I was thinking of it as being strictly a field list. I don't
On Fri, 14 Jan 2011 14:59:00 -0500
Andrew Dunstan wrote:
> Have you actually posted this version of file_fdw? I haven't seen it.
Sorry, now it's been posted.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01205.php
Regarads,
--
Shigeru Hanada
--
Sent via pgsql-hackers mailing list (
On 01/14/2011 05:08 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/14/2011 11:48 AM, Stephen Frost wrote:
My first thought would be to have a 'log_csv_format' GUC that's very
similar to 'log_line_prefix' (and uses the same variables if
possible..). We could then ship a default in postgres
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentraut wrote:
> I've been going over this patch with a fine-tooth comb for the last two
> weeks, fixed some small bugs, added comments, made initdb a little
> friendlier, but no substantial changes.
>
> I'm going to start working on SQL-level CREATE/DROP/
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp wrote:
> There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this is
> worth covering in an updated patch too?
> And if I change that, people might expect the same from DROP X IF EXISTS too?
It's far less clear what you'd change those case
On Fri, Jan 14, 2011 at 3:41 PM, Jaime Casanova wrote:
> Here is a patch that implements "named restore points".
>
> It allows DBAs to specify an exact point to which they can recover
> but that point will have a name, so they have a better control of when
> they want to stop recovery (ie: DBA's
On Fri, Jan 14, 2011 at 5:34 PM, Tom Lane wrote:
>> I'm not keen to explain to people how we broke their applications just
>> because we wanted to add new functionality AND avoid one shift/reduce
>> conflict in our SQL grammar. Avoiding changes to user code isn't third
>> on that list of three thi
and described in this message.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01096.php
2) copy_export-20110114.patch (NOT attached to this message)
This patch is attached and described in this message.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01066.php
3) 20110114-copy_export_HeapTupe
On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira
wrote:
> Em 14-01-2011 17:41, Jaime Casanova escreveu:
>>
>> Here is a patch that implements "named restore points".
>>
> Nice feature. I only read the provided documentation and it seems
> inconsistent to allow name, time, and xid at reco
Aidan Van Dyk writes:
> If there is going to be any change, how about using fixed columns (an
> possibly allowing them to be empty for stuff that's expensive to
> create/write), but adding a 1st column that contains a "version"
> identifyer. And to make it easy, maybe the PG major version as the
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements "named restore points".
Nice feature. I only read the provided documentation and it seems inconsistent
to allow name, time, and xid at recovery_target_name because (i) someone could
name the recovery point as '123456
Hi,
I propose the patch which reduces the amount of data loss
on the standby.
If you create the trigger file after replication is terminated,
the standby tries to replay all the WAL available in pg_xlog
and the archive. This behavior is OK, and it's helpful to reduce
the amount of data loss.
But
Simon Riggs writes:
> On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
>> I think the realistic options are (1) change the syntax
>> non-backward-compatibly or (2) don't add any functionality here.
> (3) think of another way.
The only third way that I can see is to invent some new, unrelated
s
Jaime Casanova writes:
> Here is a patch that implements "named restore points".
> It allows DBAs to specify an exact point to which they can recover
> but that point will have a name, so they have a better control of when
> they want to stop recovery (ie: DBA's won't depend of remember
> specif
Simon Riggs writes:
> It's a major undertaking trying to write software that runs against
> PostgreSQL for more than one release. We should be making that easier,
> not harder.
None of the proposals would make it impossible to write a LOCK statement
that works on all available releases, so I thin
On 01/14/2011 05:04 PM, Aidan Van Dyk wrote:
If there is going to be any change, how about using fixed columns (an
possibly allowing them to be empty for stuff that's expensive to
create/write), but adding a 1st column that contains a "version"
identifyer. And to make it easy, maybe the PG maj
Andrew Dunstan writes:
> On 01/14/2011 11:48 AM, Stephen Frost wrote:
>> My first thought would be to have a 'log_csv_format' GUC that's very
>> similar to 'log_line_prefix' (and uses the same variables if
>> possible..). We could then ship a default in postgresql.conf that
>> matches what the cu
On Fri, Jan 14, 2011 at 4:56 PM, Andrew Dunstan wrote:
>
> I'm not sure I really want to make it that flexible :-)
>
> To deal with the issue Tom's referring to, I think it would be sufficient if
> we just allowed users to suppress production of certain columns (as long as
> we never do anything s
On 01/14/2011 11:48 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Andrew Dunstan writes:
I think it's time to revisit the design of CSV logs again, now we have
two or three releases worth of experience with it. It needs some
flexibility and refinement.
It would definitely
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Robert Haas wrote:
>>> The critical issue is whether the tuples get frozen while
>>> they're still invisible to some transactions on the standby
>>> server. That's when you get query cancellations.
>
>> Oh, OK; I get that. That seems easy enough
"Kevin Grittner" writes:
> Robert Haas wrote:
>> The critical issue is whether the tuples get frozen while they're
>> still invisible to some transactions on the standby server.
>> That's when you get query cancellations.
> Oh, OK; I get that. That seems easy enough to at least mitigate to
>
On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
> I think the realistic options are (1) change the syntax
> non-backward-compatibly or (2) don't add any functionality here.
(3) think of another way.
I'm not keen to explain to people how we broke their applications just
because we wanted to ad
Dear pghackers,
During the last two weeks, I have enjoyed a total of 113 hours of
development of pov - PostgreSQL Object Version control system.
Version 1.0 is now finally released!
POV will not touch any of your "data" (tables, sequences, indexes) -
it will only keep track of your "logics" (fun
I wrote:
> It looks to me like the reason why there's a shift/reduce conflict is
> not so much that TABLE is optional as that we allow the syntax
> LOCK tablename NOWAIT
BTW, I did confirm this to the extent of showing that the shift-reduce
conflict could be eliminated by attaching precedenc
On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> >> No, that will not work at all. LOCK has to be a utility command.
>
> > But it doesn't break the use case for locking sequences, ISTM.
>
> You haven't stated what
Thanks for considering our special scenario. I did not use the vacuum freeze
option because the documentation said it is going to be deprecrated. Based on
the positive votes so far, I gather that a vacuum (freeze) syntax will be
supported in some version in the future, until then, I can continue
Thanks for reviewing!
On Fri, Jan 14, 2011 at 13:40, Robert Haas wrote:
> Did you check whether this updated the code for 100% of the object
> types where this could apply?
I walked through all the CREATE statements in the documentation and
these four seem to be the only ones that accept FOR REP
Simon Riggs writes:
> On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
>> No, that will not work at all. LOCK has to be a utility command.
> But it doesn't break the use case for locking sequences, ISTM.
You haven't stated what you think that use case is, but in any case
I'm sure someone can
On Fri, Jan 14, 2011 at 3:41 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I'm not wildly enthusiastic about breaking this with only one
>> intervening release. We normally support deprecated syntax for
>> quite a bit longer than that.
>
> "one intervening release"? Where did you see that
Hi,
Here is a patch that implements "named restore points".
It allows DBAs to specify an exact point to which they can recover
but that point will have a name, so they have a better control of when
they want to stop recovery (ie: DBA's won't depend of remember
specific times, dates and such).
T
Robert Haas wrote:
> I'm not wildly enthusiastic about breaking this with only one
> intervening release. We normally support deprecated syntax for
> quite a bit longer than that.
"one intervening release"? Where did you see that?
I thought we were just talking about deprecating the old sy
On Fri, Jan 14, 2011 at 2:15 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> If we're going to be supporting that long term, we should probably
>> change the note about FREEZE being deprecated, though.
>
>> So, still +1 on removing the wording about FREEZE being deprecated,
>> but instead we sh
On Fri, Jan 14, 2011 at 2:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane wrote:
>>> Freezing sooner isn't likely to reduce I/O compared to hint bits. What
>>> that does is create I/O that you *have* to execute ... both in the pages
>>> themselves, and
On 08/01/11 23:37, Alexander Korotkov wrote:
> I updated my patch to make it use full index scan in GIN index which is
> possible thanks to recent Tom Lane patch. Now wildcard, where no trigram can
> be extracted from, invokes full index scan, which is slow but correct.
Hi,
unfortunately, this ch
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
> >> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
> >> every application using any form of LOCK at all, which is what I think
> >> your proposal w
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> The reason for wanting to deprecate and ultimately remove that
> >> syntax is so we can get rid of FREEZE as a reserved word.
>
> > Oh, OK. I can go along with that. If we're going that route,
> > though, shouldn't we be getti
Simon Riggs writes:
> On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
>> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
>> every application using any form of LOCK at all, which is what I think
>> your proposal will amount to in practice.
> Can I suggest that we don't br
On 01/14/2011 07:23 AM, Shigeru HANADA wrote:
You would be able to test these patches with "20110114" version of file_fdw
wrapper patches which will be posted in another thread.
Have you actually posted this version of file_fdw? I haven't seen it.
cheers
andrew
--
Sent vi
On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
> every application using any form of LOCK at all, which is what I think
> your proposal will amount to in practice.
Can I suggest that we don't break anything at all?
pg_lo
Le 14 janv. 2011 à 20:08, Robert Haas a écrit :
> On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
>
>> So it looks to me like there are at least two fixes other than the ones
>> you enumerated:
>>
>> 1. Make NOWAIT a reserved word. Not good, but perhaps better than
>> reserving all the diffe
Robert Haas writes:
> On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane wrote:
>> Freezing sooner isn't likely to reduce I/O compared to hint bits. What
>> that does is create I/O that you *have* to execute ... both in the pages
>> themselves, and in WAL.
> It depends on which way you tilt your head -
Tom Lane wrote:
> "Kevin Grittner" writes:
>> So, still +1 on removing the wording about FREEZE being
>> deprecated, but instead we should mention what actually *is*
>> deprecated (the omission of the parentheses).
>
> If we're going to do that, we should deprecate the unparenthesized
> synta
Robert Haas writes:
> On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
>> 2. Disallow the above abbreviated syntax; allow NOWAIT only after an
>> explicit IN ... MODE phrase. This would probably break a couple of
>> applications, but I bet a lot fewer than changing the longer-established
>> part
On Fri, Jan 14, 2011 at 2:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane wrote:
>>> That 9.0 change was far less invasive than this: it only added a count
>>> field to SELECT and CTAS result tags. Quite aside from the fact that
>>> the tag name stayed
Robert Haas wrote:
> The critical issue is whether the tuples get frozen while they're
> still invisible to some transactions on the standby server.
> That's when you get query cancellations.
Oh, OK; I get that. That seems easy enough to at least mitigate to
a large degree by some threshold
Tom Lane wrote:
> Robert Haas writes:
>> Those things are related, though. Freezing sooner could be
>> viewed as an alternative to hint bits.
>
> Freezing sooner isn't likely to reduce I/O compared to hint bits.
> What that does is create I/O that you *have* to execute ... both
> in the page
"Kevin Grittner" writes:
> If we're going to be supporting that long term, we should probably
> change the note about FREEZE being deprecated, though.
> So, still +1 on removing the wording about FREEZE being deprecated,
> but instead we should mention what actually *is* deprecated (the
> omissi
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane wrote:
>>> Um, yeah, I think you're having a problem keeping all the ideas straight
>>> ;-). The argument about forensics has to do with how soon we're willing
>>> to freeze tuple
On Fri, Jan 14, 2011 at 1:52 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> Background freezing plays havoc with Hot Standby
>
> I must have missed or forgotten the issue of background vacuums
> and hot standby. Can you summarize why that's worse than hitting
> thresholds where autovacuum i
On lör, 2009-07-25 at 01:41 -0500, Jaime Casanova wrote:
> On Fri, Jul 24, 2009 at 2:23 AM, Magnus Hagander wrote:
> >>
> >> 1) it introduces a dependency for -lpgport when compiling a client
> >> that uses libpq
> >>http://archives.postgresql.org/pgsql-hackers/2009-07/msg01511.php
> >
> > For
On Fri, Jan 14, 2011 at 2:01 PM, Kevin Grittner
wrote:
>> Trouble is, it breaks Hot Standby, badly.
>
> You're really starting to worry me here. Both for performance and
> to reduce the WAN bandwidth demands of our backup strategy we are
> very aggressive with our freezing. Do off-hours VACUUM (
Robert Haas writes:
> On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane wrote:
>> Um, yeah, I think you're having a problem keeping all the ideas straight
>> ;-). The argument about forensics has to do with how soon we're willing
>> to freeze tuples, ie replace the XID with a constant. Not about hint
>
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> Tom - I am willing to implement this if you think it's valuable, but
>> I'd like your input on the syntax.
>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
>
> It looks to me like the reason why there's
Robert Haas writes:
> On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane wrote:
>> That 9.0 change was far less invasive than this: it only added a count
>> field to SELECT and CTAS result tags. Quite aside from the fact that
>> the tag name stayed the same, in the SELECT case it's unlikely anyone
>> wou
On Fri, 2011-01-14 at 13:58 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Tom - I am willing to implement this if you think it's valuable, but
> > I'd like your input on the syntax.
> > http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
>
> It looks to me like the reason why the
Robert Haas wrote:
> Freezing sooner could be viewed as an alternative to hint bits.
Exactly. And as your test showed, things run faster frozen than
unfrozen with hint bits set.
> Trouble is, it breaks Hot Standby, badly.
You're really starting to worry me here. Both for performance and
Robert Haas writes:
> Tom - I am willing to implement this if you think it's valuable, but
> I'd like your input on the syntax.
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
It looks to me like the reason why there's a shift/reduce conflict is
not so much that TABLE is optio
Robert Haas wrote:
> Background freezing plays havoc with Hot Standby
I must have missed or forgotten the issue of background vacuums
and hot standby. Can you summarize why that's worse than hitting
thresholds where autovacuum is freezing things?
> this test is sufficient to show that elimi
On Fri, Jan 14, 2011 at 1:42 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Anyway, there are so many ideas in this area, it's hard to keep them
>> all straight. Personally, if I was going to start with something,
>> it would probably be to better establish what the impact is on
>> various wo
On Fri, Jan 14, 2011 at 12:29 PM, Simon Riggs wrote:
> This whole thing is confused. No change is appropriate here at all.
>
> We issue ERRCODE_T_R_SERIALIZATION_FAILURE almost all of the time for
> recovery conflicts.
>
> We issue ERRCODE_ADMIN_SHUTDOWN only if the conflict is non-retryable,
> wh
On Fri, Jan 14, 2011 at 1:35 PM, Tom Lane wrote:
> Robert Haas writes:
>> If we're going to reject this patch on backwards-compatibility
>> grounds, we need to make an argument that the backward-compatibility
>> hazards are a real concern. So, again, has anyone complained about
>> the changes we
"Kevin Grittner" writes:
> Anyway, there are so many ideas in this area, it's hard to keep them
> all straight. Personally, if I was going to start with something,
> it would probably be to better establish what the impact is on
> various workloads of *eliminating* hint bits.
> I know some peop
On Fri, Jan 14, 2011 at 1:34 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> I'm hoping some will pick it up and play with it some more (hint,
>> hint).
>
> That was a bit of a pun, eh?
Unintentional...
> Anyway, there are so many ideas in this area, it's hard to keep them
> all straight.
Robert Haas writes:
> If we're going to reject this patch on backwards-compatibility
> grounds, we need to make an argument that the backward-compatibility
> hazards are a real concern. So, again, has anyone complained about
> the changes we made in this area in 9.0?
That 9.0 change was far less
Robert Haas wrote:
> I'm hoping some will pick it up and play with it some more (hint,
> hint).
That was a bit of a pun, eh?
Anyway, there are so many ideas in this area, it's hard to keep them
all straight. Personally, if I was going to start with something,
it would probably be to better
Robert Haas writes:
> On Fri, Jan 14, 2011 at 1:06 PM, Tom Lane wrote:
>> Well, it reinforces my opinion that it's experimental ;-). But "first
>> run" of what, exactly?
> See the test case in my OP. The "runs" in question are "select sum(1) from
> s".
>> And are you sure you're taking a who
Excerpts from Robert Haas's message of vie ene 14 15:08:27 -0300 2011:
> On Fri, Jan 14, 2011 at 1:00 PM, David E. Wheeler
> wrote:
> > On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
> >
> >> Something else that might be of interest: the patch as presented here
> >> does NOT solve the deadloc
Excerpts from David E. Wheeler's message of vie ene 14 15:00:48 -0300 2011:
> On Jan 13, 2011, at 1:58 PM, Alvaro Herrera wrote:
>
> > Something else that might be of interest: the patch as presented here
> > does NOT solve the deadlock problem originally presented by Joel
> > Jacobson. It does s
On Fri, Jan 14, 2011 at 12:07 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Robert Haas's message of vie ene 14 08:40:07 -0300 2011:
>>> Also, I don't really like the way this spreads knowledge of the
>>> completionTag out all over the backend. I think it would be better to
>>> f
1 - 100 of 167 matches
Mail list logo
