On Sun, 2004-11-14 at 22:59, Neil Conway wrote:
> On Sun, 2004-11-14 at 11:06 +, Simon Riggs wrote:
> > HASH - works OK, but a pain to administer, no huge benefit in using
>
> At least in theory, I think this could offer better performance for
> equality searches than b+-tree. Given how common
On Sun, 2004-11-14 at 11:06 +, Simon Riggs wrote:
> HASH - works OK, but a pain to administer, no huge benefit in using
At least in theory, I think this could offer better performance for
equality searches than b+-tree. Given how common those kinds of queries
are, I still think hash indexes ar
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
>> Greg is correct --- at least for btree build, which is the only index
>> type we have WAL-ified at all :-(
> Is there a place (or a single best place) to document this behaviour?
If you're talking about the
On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Greg Stark wrote:
> >> I think that's already done for CREATE INDEX/REINDEX.
>
> > I don't think so. Can someone confirm?
>
> Greg is correct --- at least for btree build, which is the only index
> type
On Fri, 2004-11-12 at 23:13, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Greg Stark wrote:
> >> I think that's already done for CREATE INDEX/REINDEX.
>
> > I don't think so. Can someone confirm?
>
> Greg is correct --- at least for btree build, which is the only index
> type
On Fri, Nov 12, 2004 at 03:49:44PM -0800, Kevin Brown wrote:
> Bruce Momjian wrote:
> >
> > Added to TODO:
> >
> > * Eliminate WAL logging for CREATE INDEX/REINDEX/CREATE TABLE AS
> > when not doing WAL archiving
>
> But that means that these operations can't be performed in a
> transa
Bruce Momjian wrote:
>
> Added to TODO:
>
> * Eliminate WAL logging for CREATE INDEX/REINDEX/CREATE TABLE AS
> when not doing WAL archiving
But that means that these operations can't be performed in a
transaction unless WAL archiving is on, right? (If I misunderstand
and thus am w
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Greg Stark wrote:
> >> I think that's already done for CREATE INDEX/REINDEX.
>
> > I don't think so. Can someone confirm?
>
> Greg is correct --- at least for btree build, which is the only index
> type we have WAL-ified at all :-(
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
>> I think that's already done for CREATE INDEX/REINDEX.
> I don't think so. Can someone confirm?
Greg is correct --- at least for btree build, which is the only index
type we have WAL-ified at all :-(
regards
Greg Stark wrote:
>
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > Added to TODO:
> >
> > * Eliminate WAL logging for CREATE INDEX/REINDEX/CREATE TABLE AS
> > when not doing WAL archiving
>
> I think that's already done for CREATE INDEX/REINDEX. The reason I mentioned
> them was to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Added to TODO:
>
> * Eliminate WAL logging for CREATE INDEX/REINDEX/CREATE TABLE AS
> when not doing WAL archiving
I think that's already done for CREATE INDEX/REINDEX. The reason I mentioned
them was to provide precedent that CREATE TAB
Added to TODO:
* Eliminate WAL logging for CREATE INDEX/REINDEX/CREATE TABLE AS
when not doing WAL archiving
---
Greg Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I agree, hence why this s
On Sat, 2004-10-23 at 00:29, Greg Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > I agree, hence why this should be a user option. The usage of this is
> > restricted to particular classes of database usage: data warehousing or
> > very large database applications. This isn't intended
Simon Riggs <[EMAIL PROTECTED]> writes:
> I agree, hence why this should be a user option. The usage of this is
> restricted to particular classes of database usage: data warehousing or
> very large database applications. This isn't intended for use in OLTP or
> web-site databases.
Well a lot of
On Fri, 2004-10-22 at 19:20, Michael Paesold wrote:
> Greg Stark wrote:
> > In Postgres CREATE TABLE AS is currently being treated as a synonym for
> > SELECT
> > ... INTO ... So I think this may be an awkward feature to add. Also, like
> > reindex the logging would still be necessary for online b
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > This is one of the reasons CREATE TABLE AS and SELECT ... INTO ... are _not_
> > necessarily the same.
>
> Sure they are. Are you confusing this with INSERT ... SELECT ?
Uhm. oops.
--
greg
Greg Stark wrote:
In Postgres CREATE TABLE AS is currently being treated as a synonym for
SELECT
... INTO ... So I think this may be an awkward feature to add. Also, like
reindex the logging would still be necessary for online backups. So this
may
be a dead-end direction in the long term.
Putting
Greg Stark <[EMAIL PROTECTED]> writes:
> This is one of the reasons CREATE TABLE AS and SELECT ... INTO ... are _not_
> necessarily the same.
Sure they are. Are you confusing this with INSERT ... SELECT ?
regards, tom lane
---(end of broadcast)---
"Michael Paesold" <[EMAIL PROTECTED]> writes:
> If I understand the original proposal correctly, there is no risk of data loss
> except in a temporary file. The data would be copied into a new file (without
> wal-logging), but after that, the file would be fsynced and the resulting
> changes would
Simon Riggs wrote:
Neil Conway wrote:
Why is that necessary?
So you can choose whether to do this or not. IMHO, it is important to
have
the optimization, but it shouldn't be the case that EVERY statement is
forced not to log.
If I risk data loss, I'd like it to be my choice to do this. This effe
> Neil Conway
> On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
> > If I could go further, I'd like to add this as an option on the command
if
> > possible, rather than a presumption that all such statements should not
be
> > logged.
>
> Why is that necessary?
>
So you can choose whether to do thi
On Fri, 2004-10-22 at 07:54, Simon Riggs wrote:
> If I could go further, I'd like to add this as an option on the command if
> possible, rather than a presumption that all such statements should not be
> logged.
Why is that necessary?
-Neil
---(end of broadcast)
> Gavin Sherry
> Just thinking of optimisations, I wonder if it would be possible to bypass
> WAL (like we do for ALTER TABLE ... SET TABLESPACE) if archiving is
> disabled, and fsync the newly created relfilenode after the data is
inserted.
>
Yes please. This is good for Data Warehousing ELT-sty
On Mon, 18 Oct 2004, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > I've got the CREATE TABLE AS restructuring almost finished, but came
> > across something that I could use some advice on. The current code
> > stores the "into" relation (and whether or not that relation has OIDs)
Neil Conway <[EMAIL PROTECTED]> writes:
> I've got the CREATE TABLE AS restructuring almost finished, but came
> across something that I could use some advice on. The current code
> stores the "into" relation (and whether or not that relation has OIDs)
> in the Query struct. This is ugly[1], but I'
I've got the CREATE TABLE AS restructuring almost finished, but came
across something that I could use some advice on. The current code
stores the "into" relation (and whether or not that relation has OIDs)
in the Query struct. This is ugly[1], but I'm not sure how to fix it.
The main reason Query
26 matches
Mail list logo
