On Wednesday, July 03, 2013 11:42 AM Simon Riggs wrote:
On 22 June 2013 05:17, Amit kapila wrote:
On Friday, June 21, 2013 11:48 PM Robert Haas wrote:
On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila
wrote:
Auto.conf - 1 Vote (Josh)
System.auto.conf - 1 Vote (Josh)
Post
On 28 June 2013 05:52, Amit Kapila wrote:
> As per my understanding Summarization of points raised by you and Andres
> which this patch should address to have a bigger win:
>
> 1. Bgwriter needs to be improved so that it can help in reducing usage
> count
> and finding next victim buffer
>(r
Hello
2013/3/20 Hadi Moshayedi :
> Hi Tom,
>
> Tom Lane wrote:
>> After thinking about that for awhile: if we pursue this type of
>> optimization, what would probably be appropriate is to add an aggregate
>> property (stored in pg_aggregate) that allows direct specification of
>> the size that th
On 2 July 2013 18:43, Noah Misch wrote:
> On Tue, Jul 02, 2013 at 10:17:08AM -0400, Robert Haas wrote:
> > So I think the first question we need to answer is: Should we just
> > reject Robins' patches en masse? If we do that, then the rest of this
> > is moot. If we don't do that, then the seco
On 22 June 2013 05:17, Amit kapila wrote:
> On Friday, June 21, 2013 11:48 PM Robert Haas wrote:
> On Thu, Jun 20, 2013 at 12:18 AM, Amit Kapila
> wrote:
> >> Auto.conf- 1 Vote (Josh)
> >> System.auto.conf - 1 Vote (Josh)
> >> Postgresql.auto.conf - 2 Votes (Zoltan, Amit)
> >> Pe
On Thursday, June 27, 2013 4:58 PM Amit Kapila wrote:
> On Wednesday, June 26, 2013 7:40 AM Kyotaro HORIGUCHI wrote:
> > I've recovered from messing up.
> >
> >
> > > Please let me have a bit of time to diagnose this.
> >
> > I was completely messed up and walking on the wrong way. I looked
> into
Hackers,
Clearly I ticked off a bunch of people by publishing "the list". On the
other hand, in the 5 days succeeding the post, more than a dozen
additional people signed up to review patches, and we got some of the
"ready for committer" patches cleared out -- something which nothing
else I did,
Hello
2013/7/2 Noah Misch :
> On Fri, Jun 28, 2013 at 12:08:21PM -0400, Noah Misch wrote:
>> On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
>> > 2013/6/28 Noah Misch :
>> > > Okay. I failed to note the first time through that while the patch uses
>> > > the
>> > > same option nam
2013/7/3 Robert Haas :
> On Tue, Jul 2, 2013 at 8:16 PM, ian link wrote:
>> We covered that earlier in the email thread, but it's the current name for
>> the query history. I think we are going to change it to something a little
>> more descriptive. I was thinking "qh" for short or "query-history"
> From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Etsuro Fujita escribió:
> > > From: Hitoshi Harada [mailto:umi.tan...@gmail.com]
> >
> > > I tried several ways but I couldn't find big problems. Small typo:
> > > s/rejunk/resjunk/
> >
> > Thank you for the review. Attached is an update
>
> I'm kinda not all that convinced that this feature does anything
> that's actually useful. If you want to save your query results, you
> can just stick "CREATE TEMP TABLE ans AS" in front of your query.
> What does that not give you that this gives you?
Convenience. It auto-increments with ea
On Tue, Jul 2, 2013 at 8:16 PM, ian link wrote:
> We covered that earlier in the email thread, but it's the current name for
> the query history. I think we are going to change it to something a little
> more descriptive. I was thinking "qh" for short or "query-history".
>
>> I'm not sure if I'll
Hey Peter,
You are correct, it is the same as the referrals option in pam_ldap. It's
also the -C (sometimes -R - it seems ldapsearch options are pretty
non-standard) option in ldapsearch.
As far as I'm aware you can't pass this in an LDAP URL, primarily because
this never gets sent to the LDAP s
Updated files with changes:
- adjusted fill-column to 78, per Noah
- added c-file-style, per Andrew
- support both "postgresql" and "postgres" directory names
- use defun instead of lambda, per Dimitri
- put Perl configuration back into emacs.samples, for Tom
I also added configuration of c-auto-
I'm fine with moving the operators over to functions. I just don't want to
implement anything that is against best practice. If we are OK with that
direction, I'll go ahead and start on the new patch.
Ian
On Mon, Jul 1, 2013 at 9:03 PM, Tom Lane wrote:
> Craig Ringer writes:
> > On 07/02/2013
>
> I haven't been able to find any real documentation on this feature,
> other than the additions to the psql help.
You're right, I missed that in my review. I agree that it needs some more
documentation.
What is "ans"?
We covered that earlier in the email thread, but it's the current name for
On Wed, Jun 19, 2013 at 9:38 PM, Peter Eisentraut wrote:
> When building without thread safety, I get the following compiler
> warning in pgbench:
>
> pgbench.c:2612:2: error: ignoring return value of function declared with
> warn_unused_result attribute [-Werror,-Wunused-result]
> write(
On 2013/07/02, at 23:44, Bruce Momjian wrote:
> I understand. You could wear "slacker" as a badge of honor: ;-)
> http://momjian.us/main/img/main/slacker.jpg
This picture could make a nice T-shirt btw.
>
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Amit Kapila escribió:
> I have changed the file name to postgresql.auto.conf and I have changed the
> name of SetPersistentLock to AutoFileLock.
>
> Zoltan,
>
> Could you please once check the attached Patch if you have time, as now all
> the things are resolved except for small doubt in syntax
On Wed, Jul 3, 2013 at 5:43 AM, Michael Paquier
wrote:
> On Wed, Jul 3, 2013 at 5:22 AM, Fujii Masao wrote:
>> Why did you remove the check of indisvalid from the --binary-upgrade SQL?
>> Without this check, if there is the invalid toast index, more than one rows
>> are
>> returned and ExecuteSq
On Mon, Jun 24, 2013 at 8:12 AM, Andres Freund wrote:
> Agreed. And it also improves the status quo when debugging. I wish this
> would have been the representation since the beginning.
>
> Some remarks:
> * I don't really like that HeapTupleHeaderXminFrozen() now is frequently
> performed witho
On Fri, Jun 28, 2013 at 12:08:21PM -0400, Noah Misch wrote:
> On Fri, Jun 28, 2013 at 05:21:29PM +0200, Pavel Stehule wrote:
> > 2013/6/28 Noah Misch :
> > > Okay. I failed to note the first time through that while the patch uses
> > > the
> > > same option names for RAISE and GET STACKED DIAGNOS
On Fri, Jun 28, 2013 at 4:30 PM, Michael Paquier
wrote:
> On Wed, Jun 26, 2013 at 1:06 AM, Fujii Masao wrote:
>> Thanks for updating the patch!
> And thanks for taking time to look at that. I updated the patch
> according to your comments, except for the VACUUM FULL problem. Please
> see patch at
On Tue, Jul 2, 2013 at 3:00 PM, Hannu Krosing wrote:
> I guess whoever registered it with CF should also take your place on the
> slackers list ;)
Yeah, I recommend that, in the future, CF managers do NOT go and add
patches to the CF. Pinging newbies to see if they just forgot is
sensible, but i
On Tue, Jun 25, 2013 at 1:42 PM, Andres Freund wrote:
> I think the usecase for this utility isn't big enough to be included in
> postgres since it really can only help in a very limited
> circumstances. And I think it's too likely to be misused for stuff it's
> not useable for (e.g. remastering).
On 07/02/2013 11:30 AM, Tatsuo Ishii wrote:
>> Folks,
>>
>> For 9.2, we adopted it as policy that anyone submitting a patch to a
>> commitfest is expected to review at least one patch submitted by someone
>> else. And that failure to do so would affect the attention your patches
>> received in the
On Tue, 2013-07-02 at 19:34 +0200, Andres Freund wrote:
> Well, I still have my doubts that it's a good idea to remove this
> knowledge from the page level. And that's not primarily related to
> performance. Unfortunately a good part of judging architectural
> questions is gut feeling...
> The only
On Tue, Jan 22, 2013 at 11:45 AM, David Fetter wrote:
> I've been working with Andrew Gierth (well, mostly he's been doing the
> work, as usual) to add WITH ORDINALITY as an option for set-returning
> functions. In the process, he found a minor opportunity to clean up
> the interface for $SUBJECT
On Tue, Jul 02, 2013 at 10:17:08AM -0400, Robert Haas wrote:
> So I think the first question we need to answer is: Should we just
> reject Robins' patches en masse? If we do that, then the rest of this
> is moot. If we don't do that, then the second question is whether we
> should try to introduc
On Tue, Jul 2, 2013 at 11:06 AM, Andres Freund wrote:
> In that case the old value will rather likely just have been read just
> before, so the price of rereading should be relatively low.
Maybe in terms of I/O, but there's still CPU.
> is a rather valid point. I've split the patch accordingly.
On 2013-07-02 10:12:31 -0700, Jeff Davis wrote:
> On Tue, 2013-07-02 at 14:02 +0200, Andres Freund wrote:
> > Ok, so you want some benchmark results. I spent 20 minutes concocting some
> > quick tests. Here you go:
> >
> > master (384f933046dc9e9a2b416f5f7b3be30b93587c63):
> > tps = 155075.448341
Abhijit Menon-Sen escribió:
> At 2013-06-24 10:16:33 +, laurenz.a...@wien.gv.at wrote:
> >
> > What do you think of the attached version?
>
> I'm not exactly fond of it, but I can't come up with a better version
> either. It's slightly better if "but may not accurately represent the
> stored v
On 2013-07-02 19:48:40 +0300, Heikki Linnakangas wrote:
> >If so, why isn't it sufficient to
> >initialize it in ReserveXLogInsertLocation?
>
> It would be, but then ReserveXLogInsertLocation would need to hold the
> slot's spinlock at the same time with insertpos_lck, so that it could
> atomicall
On Tue, 2013-07-02 at 14:02 +0200, Andres Freund wrote:
> Ok, so you want some benchmark results. I spent 20 minutes concocting some
> quick tests. Here you go:
>
> master (384f933046dc9e9a2b416f5f7b3be30b93587c63):
> tps = 155075.448341 (including connections establishing)
> tps = 155259.752267 (
On 27.06.2013 15:27, Andres Freund wrote:
Hi,
On 2013-06-26 18:52:30 +0300, Heikki Linnakangas wrote:
* Could you document the way slots prevent checkpoints from occurring
when XLogInsert rechecks for full page writes? I think it's correct -
but not very obvious on a glance.
There's thi
> On Mon, Jul 1, 2013 at 11:16 PM, Tatsuo Ishii wrote:
>> Now that we have COPY FREEZE, I'm thinking about adding similar option
>> to creating large objects. In 9.3 the maximum size of large objects
>> are increased. That means, the first access to a large object will
>> trigger more writes becau
On Tue, Jul 02, 2013 at 11:37:13AM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke wrote:
> >> Should we do something about this or we are ok with the current
> >> behavior? I would prefer to get to see the config parameter value
> >> if I so happe
On Tue, Jul 2, 2013 at 12:36 PM, Peter Geoghegan wrote:
> On Tue, Jul 2, 2013 at 5:04 AM, Atri Sharma wrote:
>>> I think if you'll try it you'll find that we perform quite well on
>>> data sets of this kind - and if you read the code you'll see why.
>>
>> Right, let me read the code again from th
On 02.07.2013 18:24, Andres Freund wrote:
I've quickly verified that it indeed uses them. I wish I hadn't. Brrr. I
can't even guess what that should do from the surrounding code/function
names. Except that it looks broken under concurrency as long as
SnapshotNow is used (because the query's snaps
On Tue, Jul 2, 2013 at 5:04 AM, Atri Sharma wrote:
>> I think if you'll try it you'll find that we perform quite well on
>> data sets of this kind - and if you read the code you'll see why.
>
> Right, let me read the code again from that viewpoint.
In my opinion, it would be worthwhile reading th
Robert Haas writes:
> On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke wrote:
>> Should we do something about this or we are ok with the current behavior? I
>> would prefer to get to see the config parameter value if I so happen to want
>> to see it before the load of that contrib module. Thoughts
What is more, it's entirely possibly to invoke pg_regress with multiple
--schedule arguments, so we could, for example, have a makefile target
that would run both the check and some other schedule of longer running
tests.
I missed this fact, because I've not seen any example of multiple sche
On 2013-07-02 10:38:17 -0400, Robert Haas wrote:
> On Tue, Jul 2, 2013 at 9:52 AM, Andres Freund wrote:
> >> > * possibly paranoid, but I'd add a Assert to heap_beginscan_catalog or
> >> > GetCatalogSnapshot ensuring we're dealing with a catalog relation. The
> >> > consistency mechanisms in G
On 2013-07-01 17:46:51 -0400, Robert Haas wrote:
> But backing up a minute, this is really a significant behavior change
> that is independent of the purpose of the rest of this patch. What
> you're proposing here is that every time we consider toasting a value
> on update, we should first check w
On Tue, Jul 2, 2013 at 4:02 AM, Hitoshi Harada wrote:
> Other than these, I've found index is opened with NoLock, relying on
> ExclusiveLock of parent matview, and ALTER INDEX SET TABLESPACE or something
> similar can run concurrently, but it is presumably safe. DROP INDEX,
> REINDEX would be blo
On Tue, Jul 2, 2013 at 9:32 AM, Nikhil Sontakke wrote:
> So, if I have a contrib module which adds in a custom guc via
> DefineCustomIntVariable() for example. Now that custom guc is not visible
> via a show command unless that corresponding .so has been loaded into
> memory.
>
> E.g.
>
> postgres
On Mon, Jul 1, 2013 at 11:16 PM, Tatsuo Ishii wrote:
> Now that we have COPY FREEZE, I'm thinking about adding similar option
> to creating large objects. In 9.3 the maximum size of large objects
> are increased. That means, the first access to a large object will
> trigger more writes because of
On 02.07.2013 13:39, Andres Freund wrote:
src/postgresql/src/pl/plpython/plpy_procedure.c: In function
‘PLy_procedure_munge_source’:
src/postgresql/src/pl/plpython/plpy_procedure.c:507:2: warning: comparison of
unsigned expression>= 0 is always true [-Wtype-limits]
Assert(plen>= 0&& plen<
On Tue, Jul 2, 2013 at 10:52:26AM +0200, Michael Meskes wrote:
> Sorry for joining the thread this late, but I didn't really expect to see
> myself listed as a slacker on a public list.
>
> > Additionally, the following committers are not listed as reviewers on
> > any patch. Note that I have no
On 07/02/2013 10:17 AM, Robert Haas wrote:
Reviewing this thread, I think that the following people are in favor
of adding the tests to the existing schedule: Josh Berkus, Stephen
Frost, Fabien Coelho, Dann Corbit, and Jeff Janes. And I think that
the following people are in favor of a new sche
On Tue, Jul 2, 2013 at 9:52 AM, Andres Freund wrote:
>> > * possibly paranoid, but I'd add a Assert to heap_beginscan_catalog or
>> > GetCatalogSnapshot ensuring we're dealing with a catalog relation. The
>> > consistency mechanisms in GetCatalogSnapshot() only work for those, so
>> > there
On Tue, Jul 2, 2013 at 12:16:18PM +0900, Tatsuo Ishii wrote:
> Now that we have COPY FREEZE, I'm thinking about adding similar option
> to creating large objects. In 9.3 the maximum size of large objects
> are increased. That means, the first access to a large object will
> trigger more writes bec
On Mon, Jul 1, 2013 at 5:59 PM, Robins Tharakan wrote:
>
> Thanks Marko for pointing out about guc.sql.
>
> Please find attached a patch to move DISCARD related tests from guc.sql to
> discard.sql. It adds an extra test for a DISCARD PLANS line, although I
> amn't sure on how to validate that its
Reviewing this thread, I think that the following people are in favor
of adding the tests to the existing schedule: Josh Berkus, Stephen
Frost, Fabien Coelho, Dann Corbit, and Jeff Janes. And I think that
the following people are in favor of a new schedule: Andres Freund,
Andrew Dunstan, David Fet
On 2013-07-02 09:31:23 -0400, Robert Haas wrote:
> On Tue, Jul 2, 2013 at 9:02 AM, Andres Freund wrote:
> > Some things that might be worth changing when committing:
> > * Could you add a Assert(!RelationHasSysCache(relid)) to
> > RelationInvalidatesSnapshotsOnly? It's not unlikely that it will
Hi,
So, if I have a contrib module which adds in a custom guc via
DefineCustomIntVariable() for example. Now that custom guc is not visible
via a show command unless that corresponding .so has been loaded into
memory.
E.g.
postgres=# show pg_buffercache.fancy_custom_guc;
ERROR: unrecognized con
On Tue, Jul 2, 2013 at 9:02 AM, Andres Freund wrote:
> Some things that might be worth changing when committing:
> * Could you add a Assert(!RelationHasSysCache(relid)) to
> RelationInvalidatesSnapshotsOnly? It's not unlikely that it will be
> missed by the next person adding a syscache and th
On Tuesday, July 02, 2013 11:16 AM Amit Kapila wrote:
> On Friday, June 28, 2013 10:41 AM Sawada Masahiko wrote:
> > On Wed, Jun 26, 2013 at 1:40 PM, Amit Kapila
> > wrote:
> > > On Tuesday, June 25, 2013 10:23 AM Amit Langote wrote:
> > >> Hi,
> > >>
> > >> >
> > >> >> So our proposal on this pro
On Tue, Jul 2, 2013 at 2:45 PM, Amit Kapila wrote:
> On Friday, June 28, 2013 10:41 AM Sawada Masahiko wrote:
>> On Wed, Jun 26, 2013 at 1:40 PM, Amit Kapila
>> wrote:
>> > On Tuesday, June 25, 2013 10:23 AM Amit Langote wrote:
>> >> Hi,
>> >>
>> >> >
>> >> >> So our proposal on this problem is t
On 2013-07-01 15:02:41 -0400, Robert Haas wrote:
> >> * These are updated by GetSnapshotData. We initialize them this way
> >> @@ -177,6 +188,9 @@ GetTransactionSnapshot(void)
> >> else
> >> CurrentSnapshot =
> >> GetSnapshotData(&CurrentSnapshotData);
> >>
>
On 7/2/13 12:20 AM, James Sewell wrote:
> Hey All,
>
> This patch request grew from this post (of mine) to pgsql-general:
>
> http://www.postgresql.org/message-id/cabuevezouae-g1_oejagujjmem675dnystwybp4d_wz6om+...@mail.gmail.com
>
> The patch adds another available LDAP option (ldapnochaseref)
On 7/2/13 5:53 AM, Maciej Gajewski wrote:
> In the meantime, I've applied your suggestions and moved the
> sting-manipulating functions to stringutils. Also fixed a tiny bug.
> Patch attached.
I haven't been able to find any real documentation on this feature,
other than the additions to the psql
On Tue, Jul 2, 2013 at 5:20 PM, Robert Haas wrote:
> On Tue, Jul 2, 2013 at 12:33 AM, Atri Sharma wrote:
>>> If you want to get a useful response to your emails, consider
>>> including a statement of what you think the problem is and why you
>>> think your proposed changes will help. Consider of
On 2013-07-02 14:02:22 +0200, Andres Freund wrote:
> Data loaded: load.sql.
Attached...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
DROP TABLE IF EXISTS kv;
CREATE TABLE kv(
id serial
On 2013-07-01 19:52:57 -0700, Jeff Davis wrote:
> 2. Can you be more specific about the scenarios that you *are* concerned
> about? Preferably in a form that could be tested on a 64-core box; but
> at least some kind of analysis involving numbers. "More page accesses"
> is scary, but completely mea
On Tue, Jul 2, 2013 at 12:33 AM, Atri Sharma wrote:
>> If you want to get a useful response to your emails, consider
>> including a statement of what you think the problem is and why you
>> think your proposed changes will help. Consider offering a test case
>> that performs badly and an analysis
Hello
remastered patch
still there is a issue with dependencies
Regards
Pavel Stehule
2013/6/17 Josh Kupershmidt :
> On Fri, Mar 8, 2013 at 11:58 AM, Pavel Stehule
> wrote:
>
>> I'll see - please, stay tuned to 9.4 first commitfest
>
> Hi Pavel,
> Just a reminder, I didn't see this patch
Hello
I would to continue on implementation --if-exists option (using
conditional DROP statements) for pg_dump
related discussion
http://www.postgresql.org/message-id/cafj8prdwqtxnc+reuavc4h5hx1f_0hkna-9f+2fgcu18axt...@mail.gmail.com
Actually, we are not able to do simple implementation due dou
Hello
2013/3/8 Josh Kupershmidt :
> [Moving to -hackers]
>
> On Sat, Feb 23, 2013 at 2:51 PM, Pavel Stehule
> wrote:
>
>> so
>>
>> * --conditional-drops replaced by --if-exists
>
> Thanks for the fixes, I played around with the patch a bit. I was sort
> of expecting this example to work (after s
Hi,
src/postgresql/src/pl/plpython/plpy_procedure.c: In function
‘PLy_procedure_munge_source’:
src/postgresql/src/pl/plpython/plpy_procedure.c:507:2: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
Assert(plen >= 0 && plen < mlen);
Which has a point, we assign s
From: "Soroosh Sardari"
I wonder if anyone could help me to find the module of pg that is
responsible for the temporal space and external sort in the PG source
code.
See src/backend/utils/sort/ for sort implementation.
That uses BufFile in src/backend/storage/file/buffile.c,
which in turn use
The query history is stored within the client, so once the user stops
the client, it is gone. But yes, it would be useful to have some tool
that would allow you to see what's in there.
I could be a command (\showans ?) that would list all :ansXXX
variables, together with the query text and the si
On Mon, Jul 1, 2013 at 8:36 PM, Pavel Stehule wrote:
> 2013/6/29 Pavel Stehule :
> > Hello
> >
> > updated patch - precious Assert, more comments
> >
> > Regards
> >
> > Pavel
> >
>
> stripped
>
Thanks.
Patch looks good to me now.
Revalidated and didn't see any issue so marking "Ready For Commit
Hello
2013/3/8 Josh Kupershmidt :
> On Fri, Mar 8, 2013 at 2:23 AM, Pavel Stehule wrote:
>> 2013/3/8 Josh Kupershmidt :
>
>>> Cool. I think it would also be useful to check that --clean may only
>>> be used with --format=p to avoid any confusion there. (This issue
>>> could be addressed in a sepa
> Folks,
>
> For 9.2, we adopted it as policy that anyone submitting a patch to a
> commitfest is expected to review at least one patch submitted by someone
> else. And that failure to do so would affect the attention your patches
> received in the future. For that reason, I'm publishing the lis
On 02.07.2013 10:55, Soroosh Sardari wrote:
Dear Hackers
Recently I find about pgsql_tmp directory. As I think, this directory is a
area for making temporal files which are used for external sort.
I wonder if anyone could help me to find the module of pg that is
responsible for the temporal spa
2013/7/1 Peter Eisentraut :
> On 7/1/13 3:47 AM, Pavel Stehule wrote:
>> and it is a part of our ToDo: "Add function to allow the creation of
>> timestamps using parameters"
>>
>> so we can have a functions with signatures
>
> I would just name them date(...), time(...), etc.
>
+1
>> CREATE OR RE
Sorry for joining the thread this late, but I didn't really expect to see
myself listed as a slacker on a public list.
> Additionally, the following committers are not listed as reviewers on
> any patch. Note that I have no way to search which ones might be
> *committers* on a patch, so these fol
At 2013-06-24 10:16:33 +, laurenz.a...@wien.gv.at wrote:
>
> What do you think of the attached version?
I'm not exactly fond of it, but I can't come up with a better version
either. It's slightly better if "but may not accurately represent the
stored value" is removed.
Does anyone else have s
On Thu, Jun 27, 2013 at 12:19 AM, Hitoshi Harada wrote:
>
>
>
> On Wed, Jun 26, 2013 at 1:38 AM, Kevin Grittner wrote:
>
>>
>
New version attached.
>>
>>
>> Will take another look.
>
>
>
Oops!
drop materialized view if exists mv;
drop table if exists foo;
create table foo(a, b) as values(1, 10);
Dear Hackers
Recently I find about pgsql_tmp directory. As I think, this directory is a
area for making temporal files which are used for external sort.
I wonder if anyone could help me to find the module of pg that is
responsible for the temporal space and external sort in the PG source code.
R
Maciej - I can see your
resistance to some kind of interactive mode. It would definitely be more
code and create a less simple user interface. I would be perfectly
happy if we left that part as it is now.
However, I think it would be important to have a way of displaying the
query history. Ye
82 matches
Mail list logo
