Simon Riggs <[EMAIL PROTECTED]> writes:
> I also suggested having three options
> --want-pre-schema
> --want-data
> --want-post-schema
> so we could ask for any or all parts in the one dump. --data-only and
> --schema-only are negative options so don't allow this.
> (I don't like those names either
On Sun, 2008-07-20 at 23:34 -0400, Tom Lane wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > * daveg ([EMAIL PROTECTED]) wrote:
> >> One observation, indexes should be built right after the table data
> >> is loaded for each table, this way, the index build gets a hot cache
> >> for the tabl
On Tue, Jul 1, 2008 at 4:13 AM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
>
> The first "half" is actually quite large, but that makes it even more
> sensible to commit this part now.
>
> The enclosed patch introduces the machinery by which we might later
> optimise hint bit setting. It differentiat
On Sun, 2008-07-20 at 21:18 -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > > Even this doesn't cover everything though- it's too focused on tables
> > > and data loading. Where do functions go? What about typ
Stephen Frost <[EMAIL PROTECTED]> writes:
> * daveg ([EMAIL PROTECTED]) wrote:
>> One observation, indexes should be built right after the table data
>> is loaded for each table, this way, the index build gets a hot cache
>> for the table data instead of having to re-read it later as we do now.
>
* daveg ([EMAIL PROTECTED]) wrote:
> One observation, indexes should be built right after the table data
> is loaded for each table, this way, the index build gets a hot cache
> for the table data instead of having to re-read it later as we do now.
That's not how pg_dump has traditionally worked,
On Sun, Jul 20, 2008 at 09:18:29PM -0400, Stephen Frost wrote:
> * Simon Riggs ([EMAIL PROTECTED]) wrote:
> > On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > > Even this doesn't cover everything though- it's too focused on tables
> > > and data loading. Where do functions go? What abo
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> > Even this doesn't cover everything though- it's too focused on tables
> > and data loading. Where do functions go? What about types?
>
> Yes, it is focused on tables and data loading. What abou
> On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
> > > > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > > > avoid LIMIT/OFFSET and FOR UPDATE as well.
> > >
> > > What of index-optimized SELECT max(...) ?
> >
> > Aggregate functions in a recursive term i
On Mon, Jul 21, 2008 at 08:19:35AM +0900, Tatsuo Ishii wrote:
> > > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > > avoid LIMIT/OFFSET and FOR UPDATE as well.
> >
> > What of index-optimized SELECT max(...) ?
>
> Aggregate functions in a recursive term is prohibited b
> > Thus I think we should avoid this kind of ORDER BY. Probably we should
> > avoid LIMIT/OFFSET and FOR UPDATE as well.
>
> What of index-optimized SELECT max(...) ?
Aggregate functions in a recursive term is prohibited by the
standard. For example,
WITH RECURSIVE x(n) AS (SELECT 1 UNION ALL
On Sun, 2008-07-20 at 17:43 -0400, Stephen Frost wrote:
> Perhaps this is up for some debate, but I find the documentation added
> for these options to be lacking the definitions I was looking for, and
> the explanation of why they are what they are. I'm also not sure I
> agree with the "Pre-Sch
Simon,
* Simon Riggs ([EMAIL PROTECTED]) wrote:
> On Sun, 2008-07-20 at 05:47 +0100, Simon Riggs wrote:
> > On Sat, 2008-07-19 at 23:07 -0400, Stephen Frost wrote:
[...]
> > > - Conflicting option handling
Thanks for putting in the extra code to explicitly indicate which
conflicting options wer
daveg <[EMAIL PROTECTED]> writes:
> Here is an updated version of this patch against head. It builds, runs and
> functions as expected. I did not build the sgml.
Applied with mostly minor cosmetic improvements --- the only actual
error I noticed was failing to check whether the server version supp
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Thus I think we should avoid this kind of ORDER BY. Probably we should
> avoid LIMIT/OFFSET and FOR UPDATE as well.
What of index-optimized SELECT max(...) ?
regards, tom lane
--
Sent via pgsql-patches mailing list (pgsql-patche
> This crashes the backend:
>
> WITH RECURSIVE t(n) AS (
> VALUES (1)
> UNION ALL
> SELECT n+1 FROM t WHERE n < 5 ORDER BY 1
> )
> SELECT n FROM t;
>
> apparently because of the ORDER BY 1
Thanks for the report. I think ORDER BY in this case is useless
anyway. ORDER BY affects (VALUES
16 matches
Mail list logo
