Robert Haas writes:
> Pushing it into the RelFileNode has some advantages in terms of being
> able to get at the information from everywhere, but one thing that
> makes me think that's probably not a good decision is that we somtimes
> WAL-log relfilenodes. And WAL-logging the value of the isTemp
On Sat, Apr 24, 2010 at 10:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> Oh, maybe I do see. If we pass it to smgropen() and stash it in the
>> SMgrRelation, we don't have to keep supplying it later on, maybe?
>
> Right. I'm unsure whether we should push it into the RelFileNode
> struct itsel
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Tom Lane wrote:
> >> The current column ordering can be rationalized to some extent as
> >>
> >> 1. identity info (user id, db id, application name)
> >> 2. current query info
> >> 3. session info (backend start time, client addr/port)
>
> > OK.
Robert Haas writes:
> Oh, maybe I do see. If we pass it to smgropen() and stash it in the
> SMgrRelation, we don't have to keep supplying it later on, maybe?
Right. I'm unsure whether we should push it into the RelFileNode
struct itself, but even having it in SMgrRelation ought to cut out
a few
On Sat, Apr 24, 2010 at 9:59 PM, Robert Haas wrote:
> On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Unfortunately, I don't see much alternative to making smgr know
>>> something about the temp-ness of the relation, though I'm hoping to
>>> keep the smgr surgery to a
On Sat, Apr 24, 2010 at 9:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unfortunately, I don't see much alternative to making smgr know
>> something about the temp-ness of the relation, though I'm hoping to
>> keep the smgr surgery to an absolute minimum. Maybe what we could do
>> is incorpora
On Apr 24, 2010, at 8:14 PM, Robert Haas wrote:
>> One possibility: rename the existing pg_stats to pg_stats_permanent. Create
>> a global temporary table called pg_stats_temporary. pg_stats becomes a union
>> of the two. I know the backend wouldn't be able to use the view, but
>> hopefully acce
Robert Haas writes:
> Unfortunately, I don't see much alternative to making smgr know
> something about the temp-ness of the relation, though I'm hoping to
> keep the smgr surgery to an absolute minimum. Maybe what we could do
> is incorporate the backend ID or PID into the file name when the
> r
Robert Haas wrote:
> On Sat, Apr 24, 2010 at 9:08 PM, Michael Tharp
> wrote:
> > The funny thing is, it doesn't seem to be a compatibility break because the
> > code in readfuncs.c that parses the node strings ignores the field names
> > entirely because it assumes they are in a particular order.
On Sat, Apr 24, 2010 at 9:08 PM, Michael Tharp
wrote:
> The funny thing is, it doesn't seem to be a compatibility break because the
> code in readfuncs.c that parses the node strings ignores the field names
> entirely because it assumes they are in a particular order. It also isn't
> much work to
On Sat, Apr 24, 2010 at 8:47 PM, Jim Nasby wrote:
> On Apr 24, 2010, at 12:31 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> At least AIUI, the use case for this feature is that you want to avoid
>>> creating "the same" temporary table over and over again.
>>
>> The context that I've seen it come
On 04/24/2010 08:49 PM, Robert Haas wrote:
The nodeToString format as it stands is somewhat ambiguous with respect to
the type of a node member's value if one does not have access to
readfuncs.c. For example, a T_BitString called foo is serialized as ':foo
b1010' while a char * containing 'b1010'
Robert Haas writes:
> On Sat, Apr 24, 2010 at 8:07 PM, Bruce Momjian wrote:
>> Sounds useful to me, though as a function like suggested in a later
>> email.
> If tool-builders think this is useful, I have no problem with making
> it available. It should be suitably disclaimed: "We reserve the r
Added to TODO:
Allow the parser output to be seen by clients
This is useful for external tools.
* http://archives.postgresql.org/pgsql-hackers/2010-04/msg00095.php
---
Robert Haas wrote:
> On Fri, Ap
On Fri, Apr 2, 2010 at 3:53 PM, Michael Tharp wrote:
> Most Esteemed Hackers:
>
> Due to popular demand on #postgresql (by which I mean David Fetter), I have
> been spending a little time making the internal SQL parser available to
> clients via a C-language SQL function. The function itself is ex
On Apr 24, 2010, at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> At least AIUI, the use case for this feature is that you want to avoid
>> creating "the same" temporary table over and over again.
>
> The context that I've seen it come up in is that people don't want to
> clutter their funct
On Sat, Apr 24, 2010 at 8:07 PM, Bruce Momjian wrote:
> Jehan-Guillaume (ioguix) de Rorthais wrote:
>> A simple example of a tokenizer is the php one:
>> http://fr.php.net/token_get_all
>>
>> And here is a basic example which return pseudo rows here :
>>
>> => TOKENIZE $script$
>> SELECT 1;
Jehan-Guillaume (ioguix) de Rorthais wrote:
> A simple example of a tokenizer is the php one:
> http://fr.php.net/token_get_all
>
> And here is a basic example which return pseudo rows here :
>
> => TOKENIZE $script$
> SELECT 1;
> UPDATE test SET "a"=2;
> $script$;
>
>type |
Takahiro Itagaki wrote:
>
> Takahiro Itagaki wrote:
>
> > Revised patch attached. Please test it.
>
> I applied this version of the patch.
> Please check wheter the bug is fixed and any buildfarm failures.
Great. I have merged in my C comments into the code with the attached
patch so we remem
On Sat, Apr 24, 2010 at 6:29 PM, Simon Riggs wrote:
> On Fri, 2010-04-23 at 22:52 -0400, Robert Haas wrote:
>> Thoughts?
>
> Only a requirement: that we design this in a way that will allow temp
> tables to be used during Hot Standby. I make not other comment.
For so long as local temporary table
On Sat, Apr 24, 2010 at 3:51 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... Why would the
>> end-of-session processing need the catalog entries? It seems like
>> whatever backend-local data structure we're using to record the
>> relfilenode mappings would be sufficent to nuke the backend stor
On Fri, 2010-04-23 at 03:08 +0200, Erik Rijkers wrote:
> It's a very easy test; I will probably run it a few more times.
Please share details of your system and hardware.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On Fri, 2010-04-23 at 22:52 -0400, Robert Haas wrote:
> Thoughts?
Only a requirement: that we design this in a way that will allow temp
tables to be used during Hot Standby. I make not other comment.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-
Robert Haas writes:
> ... Why would the
> end-of-session processing need the catalog entries? It seems like
> whatever backend-local data structure we're using to record the
> relfilenode mappings would be sufficent to nuke the backend storage,
> and what else needs doing?
Well, if you're inten
On Sat, Apr 24, 2010 at 1:38 PM, Tom Lane wrote:
> [ forgot to respond to this part ]
>
> Robert Haas writes:
>> ... I don't see the problem with DROP.
>> Under the proposed design, it's approximately equivalent to dropping a
>> table that someone else has truncated. You just wait for the
>> ne
>
> For a first cut, I had thought about ignoring the problem. Now, that
> may sound stupid, because now if two different backends have very
> different distributions of data in the table and both do an ANALYZE,
> one set of statistics will clobber the other set of statistics. On
> the flip side,
On Sat, Apr 24, 2010 at 1:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> At least AIUI, the use case for this feature is that you want to avoid
>> creating "the same" temporary table over and over again.
>
> The context that I've seen it come up in is that people don't want to
> clutter their fu
[ forgot to respond to this part ]
Robert Haas writes:
> ... I don't see the problem with DROP.
> Under the proposed design, it's approximately equivalent to dropping a
> table that someone else has truncated. You just wait for the
> necessary lock and then do it.
And do *what*? You can remov
Robert Haas writes:
> At least AIUI, the use case for this feature is that you want to avoid
> creating "the same" temporary table over and over again.
The context that I've seen it come up in is that people don't want to
clutter their functions with create-it-if-it-doesn't-exist logic,
which you
On Sat, Apr 24, 2010 at 12:11 PM, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>>> surprised to find my clone unaffected? If it modifies both, how do we
>>> avoid complete havoc if the original has since been modified (perhaps
>>> incompatibly, perhaps not) by some other backend doing its own
On Sat, 2010-04-24 at 12:59 -0400, Tom Lane wrote:
> Well, you did it without much thought at all.
To the consequences, definitely.
> I think this episode is a
> perfect demonstration of why we ask for concrete use-cases for proposed
> hooks. If you'd actually tried to write something that used
Simon Riggs writes:
> We can override table stats but not functions stats. I noticed that hole
> in the previous implementation, and rectified it with the intention of
> helping users with what I saw as a small, low risk patch that exactly
> followed existing code. It would seem I did that too qui
On Sat, 2010-04-24 at 11:17 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Sat, Apr 24, 2010 at 3:31 AM, Simon Riggs wrote:
> >> Existing hooks were not fully complete in their coverage. That has
> >> happened before, and we have discussed that before on hackers, so I took
> >> care not to d
"Greg Sabino Mullane" writes:
>> surprised to find my clone unaffected? If it modifies both, how do we
>> avoid complete havoc if the original has since been modified (perhaps
>> incompatibly, perhaps not) by some other backend doing its own ALTER
>> TABLE?
> Since this is such a thorny problem,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>...
> surprised to find my clone unaffected? If it modifies both, how do we
> avoid complete havoc if the original has since been modified (perhaps
> incompatibly, perhaps not) by some other backend doing its own ALTER
> TABLE?
Since this is
Robert Haas writes:
> On Sat, Apr 24, 2010 at 3:31 AM, Simon Riggs wrote:
>> Existing hooks were not fully complete in their coverage. That has
>> happened before, and we have discussed that before on hackers, so I took
>> care not to deviate from that implementation. This is a very low impact
>>
On Fri, 23 Apr 2010 14:34:45 -0700
Steve Atkins wrote:
> > Maybe a configuration variable along the lines of 'always_show_comments'
> > would be a better design.
>
> Or more generally an ability to set aliases via .psqlrc similar to \set,
> maybe?
>
> \alias "\d-" = "\d"
> \alias "\d" = "\d+
On Fri, 23 Apr 2010 14:28:38 -0400
Tom Lane wrote:
> If we were to do something like that, it would certainly have to affect
> every \d variant that has a + option. Which is probably not a very good
> idea --- in many cases that's a very expensive/verbose option. I can't
> get excited about thi
On Sat, Apr 24, 2010 at 3:31 AM, Simon Riggs wrote:
> On Fri, 2010-04-23 at 18:55 -0400, Tom Lane wrote:
>> sri...@postgresql.org (Simon Riggs) writes:
>> > Log Message:
>> > ---
>> > Add missing optimizer hooks for function cost and number of rows.
>> > Closely follow design of other opti
On Fri, 2010-04-23 at 19:33 -0400, Robert Haas wrote:
> Principle of obvious breakage.
That is a good principle. It can be applied both ways here.
Changing user interfaces (or indeed, anything) to very little obvious
gain is a considerable annoyance to users. IIABDFI
We need to be aware of the
On Fri, 2010-04-23 at 19:07 -0400, Robert Haas wrote:
> On Fri, Apr 23, 2010 at 6:39 PM, Simon Riggs wrote:
> > On Fri, 2010-04-23 at 11:32 -0400, Robert Haas wrote:
> >> >
> >> > 99% of transactions happen in similar times between primary and standby,
> >> > everything dragged down by rare but se
Hi, I think I've answered the question. The regress.bat is in the source code
line.
I can expand it. Just like:
..\..\..\Debug\pg_regress\pg_regress --dlpath=. --psqldir=..\..\..\Debug\psql
--schedule=serial_schedule --multibyte=SQL_ASCII --no-locale
--temp-install=.\tmp_check
--top-builddir=
On Fri, 2010-04-23 at 18:55 -0400, Tom Lane wrote:
> sri...@postgresql.org (Simon Riggs) writes:
> > Log Message:
> > ---
> > Add missing optimizer hooks for function cost and number of rows.
> > Closely follow design of other optimizer hooks: if hook exists
> > retrieve value from plugin;
43 matches
Mail list logo
